diff --git a/CP Work/Assigned/README.md b/CP Work/Assigned/README.md deleted file mode 100644 index fb9e231..0000000 --- a/CP Work/Assigned/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# DEV / CP Work -IHE Devices Domain (DEV) work products related to Change Proposals (CP's) to the domain's Technical Framework (TF). - -Note: This is modeled on the original IHE FTP site; it may be modified in the future as the TF development / maintenance process evolves. diff --git a/CP Work/Balloted Not Incorporated/README.md b/CP Work/Balloted Not Incorporated/README.md deleted file mode 100644 index fb9e231..0000000 --- a/CP Work/Balloted Not Incorporated/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# DEV / CP Work -IHE Devices Domain (DEV) work products related to Change Proposals (CP's) to the domain's Technical Framework (TF). - -Note: This is modeled on the original IHE FTP site; it may be modified in the future as the TF development / maintenance process evolves. diff --git a/CP Work/CP integration pre-publication documents/README.md b/CP Work/CP integration pre-publication documents/README.md deleted file mode 100644 index fb9e231..0000000 --- a/CP Work/CP integration pre-publication documents/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# DEV / CP Work -IHE Devices Domain (DEV) work products related to Change Proposals (CP's) to the domain's Technical Framework (TF). - -Note: This is modeled on the original IHE FTP site; it may be modified in the future as the TF development / maintenance process evolves. diff --git a/CP Work/Completed (Ready for Ballot)/README.md b/CP Work/Completed (Ready for Ballot)/README.md deleted file mode 100644 index fb9e231..0000000 --- a/CP Work/Completed (Ready for Ballot)/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# DEV / CP Work -IHE Devices Domain (DEV) work products related to Change Proposals (CP's) to the domain's Technical Framework (TF). - -Note: This is modeled on the original IHE FTP site; it may be modified in the future as the TF development / maintenance process evolves. diff --git a/CP Work/Incorporated/README.md b/CP Work/Incorporated/README.md deleted file mode 100644 index fb9e231..0000000 --- a/CP Work/Incorporated/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# DEV / CP Work -IHE Devices Domain (DEV) work products related to Change Proposals (CP's) to the domain's Technical Framework (TF). - -Note: This is modeled on the original IHE FTP site; it may be modified in the future as the TF development / maintenance process evolves. diff --git a/CP Work/Published/README.md b/CP Work/Published/README.md deleted file mode 100644 index fb9e231..0000000 --- a/CP Work/Published/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# DEV / CP Work -IHE Devices Domain (DEV) work products related to Change Proposals (CP's) to the domain's Technical Framework (TF). - -Note: This is modeled on the original IHE FTP site; it may be modified in the future as the TF development / maintenance process evolves. diff --git a/CP Work/README.md b/CP Work/README.md deleted file mode 100644 index fb9e231..0000000 --- a/CP Work/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# DEV / CP Work -IHE Devices Domain (DEV) work products related to Change Proposals (CP's) to the domain's Technical Framework (TF). - -Note: This is modeled on the original IHE FTP site; it may be modified in the future as the TF development / maintenance process evolves. diff --git a/CP Work/Submitted (incoming)/README.md b/CP Work/Submitted (incoming)/README.md deleted file mode 100644 index fb9e231..0000000 --- a/CP Work/Submitted (incoming)/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# DEV / CP Work -IHE Devices Domain (DEV) work products related to Change Proposals (CP's) to the domain's Technical Framework (TF). - -Note: This is modeled on the original IHE FTP site; it may be modified in the future as the TF development / maintenance process evolves. diff --git a/Current Published/IHE_PCD_Suppl_POU.pdf b/Current Published/IHE_PCD_Suppl_POU.pdf deleted file mode 100644 index 8626c65..0000000 Binary files a/Current Published/IHE_PCD_Suppl_POU.pdf and /dev/null differ diff --git a/Current Published/IHE_PCD_TF_Vol1 2019-12-12.pdf b/Current Published/IHE_PCD_TF_Vol1 2019-12-12.pdf deleted file mode 100644 index 6ff8ae0..0000000 Binary files a/Current Published/IHE_PCD_TF_Vol1 2019-12-12.pdf and /dev/null differ diff --git a/Current Published/IHE_PCD_TF_Vol2 2019-12-12.pdf b/Current Published/IHE_PCD_TF_Vol2 2019-12-12.pdf deleted file mode 100644 index 2c99fbc..0000000 Binary files a/Current Published/IHE_PCD_TF_Vol2 2019-12-12.pdf and /dev/null differ diff --git a/Current Published/IHE_PCD_TF_Vol3 2019-12-12.pdf b/Current Published/IHE_PCD_TF_Vol3 2019-12-12.pdf deleted file mode 100644 index 4debe39..0000000 Binary files a/Current Published/IHE_PCD_TF_Vol3 2019-12-12.pdf and /dev/null differ diff --git a/Current Published/README.md b/Current Published/README.md deleted file mode 100644 index 2aa475a..0000000 --- a/Current Published/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# DEV / Current Published -IHE Devices Domain (DEV) work products - PDF documents - that are currently cleared for publishing to the public. For example, on the [IHE Technical Frameworks web page](https://www.ihe.net/resources/technical_frameworks/#dev). - -Note: This is modeled on the original IHE FTP site; it may be modified in the future as the TF development / maintenance process evolves. diff --git a/README.md b/README.md index b1999d9..30c50c6 100644 --- a/README.md +++ b/README.md @@ -1,8 +1,38 @@ # DEV IHE Devices Domain information and formal documentation, including published technical framework and profile supplements. +## TODO +- convert the v11 drafts to AsciiDoc? (I'm pretty sure the current adoc files were converted from vol. 10. Need to check.) +- determine CP workflow and establish directory structure to support it +- craft whatever README information is needed here and for various subdirectories / repos +- create template repos for supplements and whitepapers that can be used to create new supplement / whitepaper repos. Add documentation here about how to use them. +- review notes at bottom of this file + +### Current Publications +The current versions of IHE Devices Domain (DEV) technical framework (TF) document volumes and supplements may be found on the main [IHE Devices domain page](https://profiles.ihe.net/DEV/index.html). + +### Archived Publications +Archived versions of these publications may be found [here](https://www.ihe.net/resources/technical_frameworks/technical_framework_archives/#dev). + +### Supplements and Profiles + +IHE Devices Domain (DEV) technical framework (TF) supplement work products that are either in development, in Public Comment or Trial Implementation and may be published on the [IHE Technical Frameworks web page](https://www.ihe.net/resources/technical_frameworks/#dev). + +1. Supplement revisions should also be supported until the trial implementation (TI) versions have been converted to final text (FT) and integrated into the IHE DEV TF. +2. Supplement-specific GitHub repositories contain the development artifacts for each supplement. These repositories should be frozen when the supplement content is incorporated into the TSs. CPs for the supplements should also be migrated into this repository when the supplement content is incorporated into the TFs. + +Links to other repos here. + +### Change Proposals +Useful information here. + +### Publication Tooling +Link to tooling repo here. + +### GitHub If you need assistance with an aspect of using GitHub for this repository, please contact an admin for assistance. Admins can help with inviting new collaborators to contribute content or review content. +#### Repository Administrators As of August 6, 2025 the admins for this repository are: * Todd Cooper @@ -15,9 +45,22 @@ As of August 6, 2025 the admins for this repository are: Note that this is not the list of admins for any of the other repositories that are related to IHE/DEV, such as the DEV.SDPi or DEV.PCIM repositories. +#### IHE Domain Administrators The admins for the root IHE GitHub organization are able to create new repositories and generally accomplish tasks that the admins of individual repositories may not be able to do. Those individuals are (as of Aug 7, 2025): * John Moehrke * Mary Jungers * John Rhoads * Chris Carr +---- +### Notes + +Do we need documentation about: +- how and when to create a branch +- how to commit to a branch +- how and when to create a PR +- how a PR is reviewed / accepted +- how and when new repos are created +- who the IHE root namespace admins are + +Do we need protections on the master branch? (probably yes) diff --git a/TF Supplements/POU/README.md b/Supplement Repos/POU/README.md similarity index 100% rename from TF Supplements/POU/README.md rename to Supplement Repos/POU/README.md diff --git a/TF Supplements/SDPi/README.md b/Supplement Repos/SDPi/README.md similarity index 100% rename from TF Supplements/SDPi/README.md rename to Supplement Repos/SDPi/README.md diff --git a/Supplement Repos/memdmc/AsciiDoc Source/extracted-media-memdmc/media/image1.jpeg b/Supplement Repos/memdmc/AsciiDoc Source/extracted-media-memdmc/media/image1.jpeg new file mode 100644 index 0000000..4459cc0 Binary files /dev/null and b/Supplement Repos/memdmc/AsciiDoc Source/extracted-media-memdmc/media/image1.jpeg differ diff --git a/Supplement Repos/memdmc/AsciiDoc Source/memdmc.adoc b/Supplement Repos/memdmc/AsciiDoc Source/memdmc.adoc new file mode 100644 index 0000000..816fa12 --- /dev/null +++ b/Supplement Repos/memdmc/AsciiDoc Source/memdmc.adoc @@ -0,0 +1,652 @@ +*Integrating the Healthcare Enterprise* + +image:extracted-media-memdmc/media/image1.jpeg[IHE_LOGO_for_tf-docs,width=171,height=88] + +*IHE Devices* + +*Technical Framework Supplement* + +*PCD Program* + +*Medical Equipment Management* + +*Device Management Communication* + +*(MEMDMC)* + +*Rev. 1.5 –Trial Implementation* + +Date: September 19, 2024 + +Author: IHE Devices Technical Committee + +Email: dev@ihe.net + +*Please verify you have the most recent version of this document.* See https://profiles.ihe.net/DEV/[here] for Trial Implementation and Final Text versions and https://profiles.ihe.net/DEV/#1.2[here] for Public Comment versions. + +*Foreword* + +This is a supplement to the IHE Devices Technical Framework. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks. + +This supplement is published on September 19, 2024 for trial implementation and may be available for testing at subsequent IHE Connectathons. The supplement may be amended based on the results of testing. Following successful testing it will be incorporated into the Devices Technical Framework. Comments are invited and can be submitted at https://www.ihe.net/DEV_Public_Comments/[https://www.ihe.net/DEV_Public_Comments]. + +This supplement describes changes to the existing technical framework documents. + +“Boxed” instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume. + +Amend Section X.X by the following: + +Where the amendment adds text, make the added text *[.underline]#bold underline#*. Where the amendment removes text, make the removed text *[line-through]#bold strikethrough#*. When entire new sections are added, introduce with editor’s instructions to “add new text” or similar, which for readability are not bolded or underlined. + +General information about IHE can be found at http://www.ihe.net/[IHE.net]. + +Information about the IHE Devices domain can be found at https://www.ihe.net/ihe_domains/[IHE Domains]. + +Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at https://www.ihe.net/resources/profiles/[Profiles] and https://www.ihe.net/about_ihe/ihe_process/[IHE Processes]. + +The current version of the IHE Devices Technical Framework can be found at https://profiles.ihe.net/DEV/[Devices Technical Framework]. + +CONTENTS + +link:#introduction-to-this-supplement[Introduction to this Supplement link:#introduction-to-this-supplement[5]] + +link:#open-issues-and-questions[Open Issues and Questions link:#open-issues-and-questions[5]] + +link:#closed-issues[Closed Issues link:#closed-issues[5]] + +link:#history-of-document-changes[History of Document Changes link:#history-of-document-changes[6]] + +link:#ihe-technical-frameworks-general-introduction[IHE Technical Frameworks General Introduction link:#ihe-technical-frameworks-general-introduction[7]] + +link:#copyright-licenses[9 Copyright Licenses link:#copyright-licenses[7]] + +link:#trademark[10 Trademark link:#trademark[7]] + +link:#ihe-technical-frameworks-general-introduction-appendices[IHE Technical Frameworks General Introduction Appendices link:#ihe-technical-frameworks-general-introduction-appendices[8]] + +link:#_Toc177638840[Appendix A – Actors link:#_Toc177638840[8]] + +link:#_Toc177638841[Appendix B – Transactions link:#_Toc177638841[9]] + +link:#_Toc177638842[Glossary link:#_Toc177638842[9]] + +link:#_Toc177638843[*Volume 1 – Profiles link:#_Toc177638843[11]*] + +link:#copyright-licenses-1[Copyright Licenses link:#copyright-licenses-1[11]] + +link:#domain-specific-additions[Domain-specific additions link:#domain-specific-additions[11]] + +link:#x-medical-equipment-management-device-management-communication-memdmc-profile[X Medical Equipment Management Device Management Communication (MEMDMC) Profile link:#x-medical-equipment-management-device-management-communication-memdmc-profile[12]] + +link:#x.1-memdmc-actors-transactions-and-content-modules[X.1 MEMDMC Actors, Transactions, and Content Modules link:#x.1-memdmc-actors-transactions-and-content-modules[12]] + +link:#x.1.1-actor-descriptions-and-actor-profile-requirements[X.1.1 Actor Descriptions and Actor Profile Requirements link:#x.1.1-actor-descriptions-and-actor-profile-requirements[13]] + +link:#x.1.1.1-device-management-information-reporter-dmir[X.1.1.1 Device Management Information Reporter (DMIR) link:#x.1.1.1-device-management-information-reporter-dmir[13]] + +link:#x.1.1.2-device-management-information-consumer-dmic[X.1.1.2 Device Management Information Consumer (DMIC) link:#x.1.1.2-device-management-information-consumer-dmic[13]] + +link:#x.2-memdmc-actor-options[X.2 MEMDMC Actor Options link:#x.2-memdmc-actor-options[14]] + +link:#x.3-memdmc-required-actor-groupings[X.3 MEMDMC Required Actor Groupings link:#x.3-memdmc-required-actor-groupings[14]] + +link:#x.4-memdmc-overview[X.4 MEMDMC Overview link:#x.4-memdmc-overview[14]] + +link:#x.4.1-concepts[X.4.1 Concepts link:#x.4.1-concepts[14]] + +link:#x.4.2-use-cases[X.4.2 Use Cases link:#x.4.2-use-cases[14]] + +link:#x.4.2.1-use-case-1-equipment-observations-to-cmms[X.4.2.1 Use Case #1: Equipment Observations to CMMS link:#x.4.2.1-use-case-1-equipment-observations-to-cmms[14]] + +link:#x.4.2.1.1-equipment-observations-to-cmms-use-case-description[X.4.2.1.1 Equipment Observations to CMMS Use Case Description link:#x.4.2.1.1-equipment-observations-to-cmms-use-case-description[15]] + +link:#x.4.2.1.2-equipment-observations-to-process-flow[X.4.2.1.2 Equipment Observations to Process Flow link:#x.4.2.1.2-equipment-observations-to-process-flow[15]] + +link:#x.5-memdmc-security-considerations[X.5 MEMDMC Security Considerations link:#x.5-memdmc-security-considerations[16]] + +link:#x.6-memdmc-cross-profile-considerations[X.6 MEMDMC Cross Profile Considerations link:#x.6-memdmc-cross-profile-considerations[16]] + +link:#__RefHeading__51_897662812[*Volume 2 – Transactions link:#__RefHeading__51_897662812[17]*] + +link:#device-management-information-observation-dmio-pcd-15[3.15 Device Management Information Observation (DMIO) [PCD-15] link:#device-management-information-observation-dmio-pcd-15[17]] + +link:#scope[3.15.1 Scope link:#scope[17]] + +link:#actor-roles[3.15.2 Actor Roles link:#actor-roles[17]] + +link:#referenced-standards[3.15.3 Referenced Standards link:#referenced-standards[18]] + +link:#messages[3.15.4 Messages link:#messages[19]] + +link:#device-management-information-observation-dmio-pcd-15-1[3.15.4.1 Device Management Information Observation (DMIO) [PCD-15] link:#device-management-information-observation-dmio-pcd-15-1[19]] + +link:#hl7-conformance-statement[3.15.4.1.2 HL7 Conformance Statement link:#hl7-conformance-statement[19]] + +link:#device-management-information-observation-pcd-15-orur44oru_r44-static-definition[3.15.4.1.3 Device Management Information Observation [PCD-15] (ORU^R44^ORU_R44) Static Definition link:#device-management-information-observation-pcd-15-orur44oru_r44-static-definition[20]] + +link:#trigger-events[3.15.4.1.4 Trigger Events link:#trigger-events[21]] + +link:#message-semantics[3.15.4.1.5 Message Semantics link:#message-semantics[21]] + +link:#expected-actions[3.15.4.1.6 Expected Actions link:#expected-actions[22]] + +link:#security-considerations[3.15.5 Security Considerations link:#security-considerations[22]] + +link:#volume-2-namespace-additions[Volume 2 Namespace Additions link:#volume-2-namespace-additions[22]] + +link:#_Toc177638875[Appendices to Volume 1 link:#_Toc177638875[23]] + +link:#appendix-a-transaction-examples[Appendix A – Transaction Examples link:#appendix-a-transaction-examples[23]] + +link:#a.1-device-management-information-observation[A.1 Device Management Information Observation link:#a.1-device-management-information-observation[23]] + +link:#__RefHeading__73_897662812[*Volume 3 – Content Modules link:#__RefHeading__73_897662812[25]*] + +link:#namespaces-and-vocabularies[5 Namespaces and Vocabularies link:#namespaces-and-vocabularies[25]] + +link:#content-modules[6 Content Modules link:#content-modules[25]] + +link:#_Toc177638881[Volume 3 Namespace Additions link:#_Toc177638881[25]] + +link:#__RefHeading__81_897662812[*Volume 4 – National Extensions link:#__RefHeading__81_897662812[26]*] + +link:#national-extensions[4 National Extensions link:#national-extensions[26]] + +== Introduction to this Supplement + +This supplement affects Volumes 1 and 2 of the Devices Technical Framework. The supplement adds a new profile, new actors, new triggers, and a new transaction. This supplement defines a profile for the communication of detailed device component identification, hardware and software versioning information, and device, battery, and power source status in the absence of patient observations, alerts, or event notifications. + +=== Open Issues and Questions + +Identification of some observation identifications (MDC & REFID) may not be currently defined in Rosetta Terminology Mapping (RTM) or in IEEE 11073-10101 Nomenclature. Submissions will be required as needed. In the interim, an MDC value of zero and a REFID prefix of MDCX shall be utilized until official values are assigned. After provisional values are assigned they are expected to appear in the most recent update and version of the Rosetta Terminology Mapping Management System (RTMMS) prior to being balloted for an update to the standard. Once assigned official values, implementations shall use the assigned values. + +A unique to this profile HL7 v2 message trigger has been granted by HL7 v2 Orders and Observations to replace current use of trigger value R01. This profile utilizes unsolicited observations and therefore MSH-9-1 Message Code shall remain ORU. The HL7 that granted trigger value is R44, is queued to first appear in a v 2.9.x release of HL7 v2, and replaces R01 in the MSH-9 Message Type field in both MSH-9-2 Trigger and MSH-9-3 Message Structure components in examples and references within this document have been updated accordingly. This trigger change while impacting to existing products, test tools, and deployments will allow transactions of this profile to utilize a message structure unique to this profile which will permit discontinuance of use of the message structure associated with R01. This change will allow transactions of this profile to exclude the R01 structure required HL7 message segments associated with electronic patient healthcare information (ePHI) contained in the PID Patient Identification and PV1 Patient Visit segments. Observation producer and consumer actors associated with this profile do not make use of and do not administer ePHI. Removal of ePHI message content which is not required by this profile assures patient confidentiality and avoids transaction consuming actors from requiring a HIPAA (Health Insurance Portability and Accountability Act of 1996) Business Associate agreement. This migration will also allow the deprecation of the profile transaction options associated with ePHI. + +When copying OBX instances from consumed transactions of this profile to reporter transactions of other profiles, such as DEC, IPEC, ACM, etc., the dotted notation values in OBX-4 should bear scrutiny for hierarchical conflicts with OBX-4 values of OBX instances associated with the base reporter content into which the OBX instances of this profile are being copied. + +=== Closed Issues + +Communication of the same information that this profile communicates as observations in conjunction with the data, alert, and event use cases associated with existing PCD profiles can be accomplished using the observation documentation found in this profile as additional observations to existing transactions in association with existing actors without the requirement for vendor adoption of this new profile. The justification for this additional profile is the definition of a new actor type (CMMS, or more specifically a CEMS) which is distinct from existing actors as well as the trigger condition which is unrelated to any device associated patient. + +Other methods for communication of equipment information exist in the operating environment (SNMP, vendor proprietary SOAP/XML, etc.) today, are expected to continue to exist, but are not expected to integrate with medical device data communication. + +=== History of Document Changes + +This section provides a brief summary of changes and additions to this document. + +[width="100%",cols="15%,14%,71%",options="header",] +|=== +|Date |Document Revision |Change Summary +|2024-SEP |1.5 a| +Updated for approved CPs, housekeeping corrections + +[width="100%",cols="18%,27%,55%",options="header",] +!=== +!CP # !CP Approval Date !CP Title +!DEV-003 !2024-06-12 !MEM DMC Trigger and Template +!=== + +|2023-04-07 |1.4 a| +Updated for approved CPs, housekeeping corrections, and replacing MDCXs with allocated MDCs and REFIDs. + +The following CPs were integrated. + +[width="100%",cols="19%,26%,55%",options="header",] +!=== +!CP # !CP Approval Date !CP Title +!111 !2015-02-27 !Move equipment name from OBX-18 to OBX-5 +!119 !2015-03-06 !Clarification of Observation Result Status OBX-11 as F +!152 !2020-11-20 !MEMDMC Use of MDC_OBS_MEM in OBR-4 in [PCD-15] +!=== + +|2017-11-09 |1.3 |Updated for approved CPs, housekeeping corrections, and explanation that MDCs and REFIDs need to be standardized and that they will appear first in RTMMS. +|2015-10-14 |1.2 |Updated for approved CPs and housekeeping corrections. +|=== + +== IHE Technical Frameworks General Introduction + +The https://profiles.ihe.net/GeneralIntro[IHE Technical Frameworks General Introduction] is shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to this document where appropriate. + +== Copyright Licenses + +IHE technical documents refer to, and make use of, a number of standards developed and published by several standards development organizations. Please refer to the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-9.html[Section 9 - Copyright Licenses] for copyright license information for frequently referenced base standards. Information pertaining to the use of IHE International copyrighted materials is also available there. + +== Trademark + +IHE^®^ and the IHE logo are trademarks of the Healthcare Information Management Systems Society in the United States and trademarks of IHE Europe in the European Community. Please refer to the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-10.html[Section 10 - Trademark] for information on their use. + +== IHE Technical Frameworks General Introduction Appendices + +The https://profiles.ihe.net/GeneralIntro/index.html[IHE Technical Framework General Introduction Appendices] are components shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to these documents where appropriate. + +Update the following appendices to the General Introduction as indicated below. Note that these are *not* appendices to this domain’s Technical Framework (TF-1, TF-2, TF-3 or TF-4) but rather, they are appendices to the IHE Technical Frameworks General Introduction located https://profiles.ihe.net/GeneralIntro/index.html[here]. + +*NEW: REQUIRED APPROVAL OF ACTORS, TRANSACTIONS and TERMS -* To avoid duplication and ensure consistency across domains, all *new or modified* actors, transactions and glossary terms need approval by IHE’s Domain Coordination Committee (DCC) before they are published in a trial implementation supplement. Please see https://wiki.ihe.net/index.php/Approval_Process_for_IHE_Actors,_Transactions_and_Glossary_Terms[this Wiki page] for additional guidance and links to the forms for approval submission. + +== https://profiles.ihe.net/GeneralIntro/ch-A.html[[#_Toc177638840 .anchor]####Appendix A] – Actors + +Add the following *new or modified* actors to the https://profiles.ihe.net/GeneralIntro/ch-A.html[IHE Technical Frameworks General Introduction Appendix A]: + +The Device Management Information Reporter (DMIR) produces observations. + +The Device Management Information Consumer (DMIC) consumes observations. + +[width="100%",cols="47%,53%",] +|=== +|Actor |Definition +|Device Management Information Reporter (DMIR) |Transmits observations of device identification (unique identification, versions for software, firmware, hardware) and status (power, power source, battery, self-test, etc.). +|Device Management Information Consumer (DMIC) |Receives device identification and status information. +|=== + +The Device Management Information Reporter (DMIR) may also be an actor in a different profile (DEC DOR, ACM AR, IPEC DOR). The Device Management Information Consumer (DMIC) is a new and distinct destination actor and is likely to be a Computerized Maintenance Management System (CMMS), or more specifically a Clinical Equipment Management System (CEMS), but may also be an actor in a different profile (DEC DOC, ACM AM, IPEC DOC). + +== https://profiles.ihe.net/GeneralIntro/ch-B.html[[#_Toc177638841 .anchor]####Appendix B] – Transactions + +Add the following *new or modified* transactions to the https://profiles.ihe.net/GeneralIntro/ch-B.html[IHE Technical Frameworks General Introduction Appendix B]: + +Device Management Information Observation (DMIO) [PCD-15] (from DMIR to DMIC) + +[width="100%",cols="30%,70%",] +|=== +|New (or modified) Transaction Name and Number |Definition +|Device Management Information Observation (DMIO) [PCD-15] |Contains observations of device identification (unique identification, versions for software, firmware, hardware) and status (power, power source, battery, self-test, etc.). This transaction might not commonly contain patient associated information and would likely be destined for a CMMS and not for an EMR for EHR storage. +|=== + +== Glossary + +Add the following *new or modified* glossary terms to the https://profiles.ihe.net/GeneralIntro/ch-D.html[IHE Technical Frameworks General Introduction Appendix D]: + +[width="100%",cols="26%,44%,14%,16%",options="header",] +|=== +|New (or modified) Glossary Term |Definition |Synonyms a| +Acronym/ + +Abbreviation + +|Clinical Equipment Management System |A clinical equipment specific variant of a CMM | |CEMS +|Computerized Maintenance Management System |This is the system which the hospital makes use of to maintain its inventory of medical devices, their identification, their status, their software, firmware, and hardware versioning information and history. This is a system for which reception of device location observation is well suited as a means of identifying the last known location of equipment in need of servicing, repairs, or version upgrades. | |CMMS +|Electronic Protected Health Information |Protected health information (PHI) that is produced, saved, transferred or received in an electronic form. In the United States, ePHI management is covered under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule. | |ePHI +|Health Insurance Portability and Accountability Act of 1996 |The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a federal law that required the creation of national standards to protect sensitive patient health information from being disclosed without the patient’s consent or knowledge. The US Department of Health and Human Services (HHS) issued the HIPAA Privacy Rule to implement the requirements of HIPAA. The HIPAA Security Rule protects a subset of information covered by the Privacy Rule. See https://www.cdc.gov/phlp/publications/topic/hipaa.html. | |HIPAA +|=== + +[#_Toc177638843 .anchor]####Volume 1 – Profiles + +=== Copyright Licenses + +Add the following to the IHE Technical Frameworks General Introduction Copyright section: + +NA + +=== Domain-specific additions + +None + +Add Section X + +== X Medical Equipment Management Device Management Communication (MEMDMC) Profile + +Existing profile transaction observation information does not include detailed device component identification, hardware and software versioning information, and device, self-test, battery, and power source status. + +Specific triggers, transactions, and destination actors in existing profiles do not exist for the sole purpose of communication of detailed device component identification, hardware and software versioning information, and device, battery, and power source status in the absence of patient observations, alerts, or event notifications. The absence of the communication of this information outside of patient observations, alerts, or event notifications reduces the effectiveness of CMMS solutions and impacts the effectiveness of the management of medical equipment by not permitting the tracking of hardware and software versioning information across multiple patient uses for the same device or battery utilization and battery cycling in the absence of patient associations. + +This is not the reporting of a patient associated medical device observational data as would be accomplished using the Device to Enterprise Communication (DEC) Profile. + +This is not the reporting of a patient associated operational event as would be accomplished using an Event Communication (EC) associated profile or device specialization, such as Infusion Pump Event Communication (IPEC). + +This is not the reporting of an Alert for response by a person as that would be accomplished by the Alert Communication Management (ACM) Profile. + +This profile is a combination of profile types as it defines workflow through use case specification and transport through its described use of the HL7 v2 and IEEE 11073 standards for information communication. + +=== X.1 MEMDMC Actors, Transactions, and Content Modules + +This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A at http://www.ihe.net/Technical_Frameworks/[http://www.ihe.net/Technical_Frameworks]. + +Figure X.1-1 shows the actors directly involved in the MEMDMC Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines. Actors which have a mandatory grouping are shown in conjoined boxes. + +Figure X.1-1: MEMDMC Actor Diagram + +Table X.1-1 lists the transactions for each actor directly involved in the MEMDMC Profile. To claim compliance with this profile, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”). + +Table X.1-1: MEMDMC Profile - Actors and Transactions + +[width="99%",cols="24%,30%,22%,24%",options="header",] +|=== +|Actors |Transactions |Optionality |Reference +|DMIR |DMIO [PCD-15] |R |PCD TF-2: 3.15 +|DMIC |DMIO [PCD-15] |R |PCD TF-2: 3.15 +|=== + +==== X.1.1 Actor Descriptions and Actor Profile Requirements + +Most requirements are documented in Transactions (Volume 2) and Content Modules (Volume 3). This section documents any additional requirements on profile’s actors. + +===== X.1.1.1 Device Management Information Reporter (DMIR) + +The Device Management Information Reporter (DMIR) may also be an observation transaction sending actor in other IHE PCD profiles, such as a DEC DOR, an ACM AR, or an IPEC DOR. If that is the case then the observations defined in this document may be included in existing observation content for those profiles without adoption of this profile, unless the destination to which the observations are being sent is a CMMS and not an EMR/EHR system. If that the case then this profile should be implemented. + +===== X.1.1.2 Device Management Information Consumer (DMIC) + +It is not highly probable that the Device Management Information Consumer (DMIC) is an actor in other IHE PCD profiles. The CMMS specific role of the DMIC Actor is the justification for this unique profile as a medical device sending the observations is likely to require the destination configuration and message content for the DMIC Actor to be different from those of other IHE profile actors, such as the EMR/EHR system. + +=== X.2 MEMDMC Actor Options + +Options that may be selected for each actor in this profile, if any, are listed in the Table X.2-1. Dependencies between options when applicable are specified in notes. + +Table X.2-1: MEMDMC - Actors and Options + +[width="100%",cols="26%,44%,30%",options="header",] +|=== +|Actor |Option Name |Reference +|DMIR |No option defined |-- +|DMIC |No option defined |-- +|=== + +=== X.3 MEMDMC Required Actor Groupings + +There are no required actor groupings. + +=== X.4 MEMDMC Overview + +MEMDMC is focused with sending equipment identification observations whether or not there is a patient associated with the device to equipment management systems, such as CMMS. + +==== X.4.1 Concepts + +Equipment identification, configuration, and status information needs to be recorded for effective management of the equipment, whether or not there is a patient currently associated with the equipment. + +==== X.4.2 Use Cases + +If the observations identified in this profile are added to messages of existing profiles then conformance to this profile is not required. However if the destination of the observations is not in conjunction with a device associated patient or are meant to be received by an equipment management system (CMMS) this conformance to this profile is required. + +===== X.4.2.1 Use Case #1: Equipment Observations to CMMS + +In this use case equipment observations are sent to the CMMS, whether or not the equipment is currently associated with a patient. + +If the observation is of a condition for which notification of a person is required for prioritized attention then that should be an additional alert notification to an ACM AM and this profile is not appropriate. Simply define a new alert and add the observation to it as an ACM [PCD-04] transaction. + +Depending upon information in the observation sent to the CMMS, the CMMS can choose to originate an ACM [PCD-04] advisory alert transaction as an ACM AR Actor in order to get someone to tend to an equipment issue. + +====== X.4.2.1.1 Equipment Observations to CMMS Use Case Description + +When a piece of equipment undergoes a status or configuration change, ends a battery charging cycle, or executes a self-test, and has a status to report, it reports it as an observation. The following is a sample list of situations under which observations would be reported. This is not a complete list as new observations are expected to be able to be accommodated without updating this profile. If equipment location tracking information is available (where embedded or through coordination with a gateway) that information can be included as additional observations in this transaction without adopting the MEMLS Profile. + +* Equipment power up (a last seen indication) +* Equipment network configuration is about to change (in case the change takes it offline) +* Equipment power transitions from mains to battery or back to mains (in case of battery failure) +* Self-test status is being reported and whether it failed or not (last known health) +* Battery status/level for all batteries is being reported (last known battery health) +* Battery charging success is being reported (last known battery health) +* Preventative maintenance cycle status being reported (metering) + +This is not the reporting of a patient associated operational event as would be accomplished using an Event Communication (EC) associated profile or device specialization, such as Infusion Pump Event Communication (IPEC). + +This is not the reporting of an Alert for response by a person as that would be accomplished by the Alert Communication Management (ACM) Profile. + +====== X.4.2.1.2 Equipment Observations to Process Flow + +Figure X.4.2.1.2-1: Basic Process Flow in MEMDMC Profile + +=== X.5 MEMDMC Security Considerations + +During the profile development there were no unusual security or privacy concerns identified. There are no mandatory security controls but the implementer is encouraged to use the underlying security and privacy profiles from ITI that are appropriate to the transports such as the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk assessment, following ISO 80001, will determine the actual security and safety controls employed. + +=== X.6 MEMDMC Cross Profile Considerations + +A DMIR is likely to also be a DEC DOR, an ACM AR, an IPEC DOR, or a MEMLS LIOR. There is no grouping required. + +[#__RefHeading__51_897662812 .anchor]## + +Volume 2 – Transactions + +Add Section 3.15 + +=== 3.15 Device Management Information Observation (DMIO) [PCD-15] + +==== 3.15.1 Scope + +This transaction is used to report equipment management observations whether or not the equipment is currently associated with a patient. + +==== 3.15.2 Actor Roles + +The DMIR sends the DMIO to the DMIC. + +Figure 3.15.2-1: Use Case Diagram + +The roles in this transaction are defined in the following table and may be played by the actors shown here: + +Table 3.15.2-1: Actor Roles + +[width="100%",cols="18%,82%",] +|=== +|*Role:* |Producer +|*Actor(s):* a| +The following actors may play the role of Producer: + +____ +Device Management Information Reporter (DMIR) +____ + +|*Role:* |Consumer +|*Actor(s):* a| +The following actors may play the role of Consumer: + +____ +Device Management Information Consumer (DMIC) +____ + +|=== + +==== 3.15.3 Referenced Standards + +HL7 v2.6, transitioning to v2.9.x once published for new trigger/template, Chapter 7 Observations + +IEEE 11073-10101, minimally version B, with additional MDC/REFID values not yet in the standard (as identified by MDCX indicated value of zero and the interim REFID values). + +Identification of some observation identifications (MDC & REFID) might not be currently defined in Rosetta Terminology Mapping (RTM) or in IEEE 11073-10101 Nomenclature in which case a submission will be required. These are maintained external to this profile and thus have a low probability of new change proposals to this profile. After values are assigned they are likely to appear in the Rosetta Terminology Mapping Management System (RTMMS) prior to being balloted for an update to the standard. Once assigned official values implementations shall use the assigned values. + +Below is a mapping table with an indication as to whether or not the REFID string changed from the trial to the allocated values. To reduce transcription errors, table content has been kept to a minimum. For additional details, such as value descriptions, units of measure, partition codes, and enumerations, refer to the IEEE 11073-10101 standard (normative and balloted versions) or RTMMS. + +Table 3.15.3-1: IEEE Nomenclature Mapping from preliminary to assigned + +[width="100%",cols="47%,41%,12%",options="header",] +|=== +|Trial Values |Allocated Values |Changed +|none |69135^MDC_OBS_MEM^MDC |Y +a| +0^MDCX_DMC_ATTR_POWER_STAT^MDC + +or + +67925^MDC_DMC_ATTR_POWER_STAT^MDC + +|67925^MDC_ATTR_POWER_STAT^MDC |N +|=== + +==== 3.15.4 Messages + +Figure 3.15.4-1: Interaction Diagram + +===== 3.15.4.1 Device Management Information Observation (DMIO) [PCD-15] + +The observations are mapped to OBX segment and contained under an OBR segment. + +A single transaction should report a single observation about a single piece of equipment. + +More than one sending actor instance can send to the same receiving actor instance. + +====== 3.15.4.1.2 HL7 Conformance Statement + +The conformance statement for this interaction described below is adapted from HL7 version 2.6 with use of the Participation Information (PRT) segment from HL7 version 2.7. + +Table 3.15.4.1.2-1: Device Management Information Observation [PCD-15] Transaction Conformance + +[width="100%",cols="35%,65%",options="header",] +|=== +|Publication ID: |R44 +|Type: |Unsolicited +|Publication Name: |IHEPCD-15DeviceManagementInformationObservation +|Trigger: |See Section 3.15.4.1.5 Trigger Events +|Mode: |Immediate +|Response: |ORU^R44^ORU_R44 +|Characteristics: |Sends device management information observation data +|Purpose: |Report Device Management Information Observation from DMIR to DMIC +|Based on Segment Pattern: |R44 +|=== + +====== 3.15.4.1.3 Device Management Information Observation [PCD-15] (ORU^R44^ORU_R44) Static Definition + +The Device Management Information Observation [PCD-15] message is used to communicate device management information observation data from a Device Management Information Observation Reporter (DMIR) to a Device Management Information Observation Consumer (DMIC). + +Common HL7 segments are defined in DEV TF-2: Appendix B. Sections below discuss considerations specific to [PCD-15]. + +Table 3.15.4.1.3-1: ORU^R44^ORU_R44 HL7 Attribute Table + +[width="100%",cols="13%,39%,16%,15%,17%",options="header",] +|=== +|Segment |ORU Message |Usage |Card. |HL7 Ref +|MSH |Message Header Segment |R |[1..1] |2.15.9 +|OBR |Observation Request Segment |R |[1..n] |7.4.1 +|OBX |Observation Result Segment |R |[1..n] |7.4.2 +|[PRT] |Participation Information Segment |O |[0..n] See Note |7.4.4 (V2.7) +|=== + +Note: Use of PRT is required for communicating identification of referenced other equipment. + +Table 3.15.4.1.3-2: ORU^R44^ORU_R44 Static Definition + +[width="100%",cols="47%,53%",options="header",] +|=== +|ORU^R44^ORU_R44 |Device Management Information Observation Message +|MSH |Message Header +|[\{SFT}] |Software Segment +|\{ |--- REPORT DEVICE MANAGEMENT INFORMATION OBSERVATION begin +|OBR |Device Management Information Observation Identification +|\{ |--- OBSERVATION begin +|\{OBX} |Device Management Information observations relative to OBR +|[PRT] |Participation identifies person or equipment +|} |--- OBSERVATION end +|} |--- REPORT MANAGEMENT INFORMATION OBSERVATION end +|=== + +Note: Per ORU R44 message template, PID and PV1 segments shall not be used, (X) usage. If patient identification or patient assigned location are to be communicated between DMIR and DMIC actors in a specific deployment, it shall only be through deployment documented concurrence between DMIR and DMIC actor vendor system representatives, preceded by review of justifications or requirements and HIPAA implications regarding sending and receiving of ePHI, and shall only be communicated using the PRT segment. + +====== 3.15.4.1.4 Trigger Events + +The HL7 trigger event is ORU^R44^ORU_R44. + +The identification of a MEMDMC packaged group of observations shall be encoded in the value of OBR-4 Universal Service Identifier (CWE data type) of the OBR segment as + +69135^MDC_OBS_MEM^MDC + +Specific MDC codes and REFIDs for triggers are listed in the Rosetta Terminology Mapping Management System (RTMMS). This permits new triggers to be added for use in OBX-5 Observation Value field of OBX Observation/Result instance segments to be used by this profile without a version update of this document. + +[arabic] +. Equipment power up +. Equipment network configuration is about to change +. Equipment power transitions from mains to battery or back to mains +. Self-test status is being reported (whether it failed or not) +. Battery status/level for all batteries is being reported +. Battery charging success is being reported + +====== 3.15.4.1.5 Message Semantics + +The message is an HL7 observation. The content of the message is governed by HL7, IHE PCD Technical Framework and this profile. The objects for which the observations are being reported are governed by IEEE 11073. + +The MDS, VMD, CHAN, and METRICs are to be reported per the IHE PCD Technical Framework. + +When a [PCD-15] transaction is used for the purpose of communication of a packaged group of medical device observations for the purpose of equipment management primary identification of a MEMDMC group of observations shall be encoded in the value of OBR-4 Universal Service Identifier (CWE data type) of the OBR segment as + +69135^MDC_OBS_MEM^MDC + +Specific MDC codes and REFIDs for triggers and observations are listed in the Rosetta Terminology Mapping Management System (RTMMS). This permits new triggers and observations to be added without a version update of this document. + +Identification of some observation identifications (MDC & REFID) may not be currently defined in Rosetta Terminology Mapping (RTM) or in IEEE 11073-10101 Nomenclature. Submissions will be required as needed. In the interim an MDC value of zero and a REFID prefix of MDCX shall be utilized until provisional values have been assigned. After provisional values are assigned they are expected to appear in the most recent update and version of the Rosetta Terminology Mapping Management System (RTMMS) prior to being balloted for an update to the standard. Once provisional values are assigned implementations shall use the assigned values. + +Indicating Observation Result Status (OBX-11) as a value of R (Results entered – not verified) establishes an expectation that someone will manually verify the value of the observation. Review and verification of DMC Profile specific observations (primarily observations of equipment battery, power, and self-test status) is not expected as they change over time and requiring someone to review and certify them is a workload with little return for the effort. Therefore DMC observations shall indicate a value of F (Final) in Observation Result Status (OBX-11). + +====== 3.15.4.1.6 Expected Actions + +In response to the receipt of the message the receiver will generate an HL7® acknowledgement to advise the sending of the status of the receipt of the message that was sent. + +As a result of receiving the observation the receiver can store the information for later retrieval or the information can be used to trigger the production of transactions in other IHE profiles, such the generation of an ACM alert. + +==== 3.15.5 Security Considerations + +During the profile development there were no unusual security or privacy concerns identified. There are no mandatory security controls but the implementer is encouraged to use the underlying security and privacy profiles from ITI that are appropriate to the transports such as the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk assessment, following ISO 80001, will determine the actual security and safety controls employed. + +== Volume 2 Namespace Additions + +Add the following terms to the IHE General Introduction Appendix G: + +The following OIDs have been allocated to the MEMDMC Profile. + +Specific IHE-PCD Transactions: 1.3.6.1.4.1.19376.1.6.15.9 / 1.3.6.1.4.1.19376.1.6.1.15.1 (PCD-15). + +The 1.3.6.1.4.1.19376.1.6.1.15.1 will appear in MSH-21 to identify the [PCD-15] transaction. + +Specific IHE-PCD Conformance profiles: 1.3.6.1.4.1.19376.1.6.6.15.1 [PCD-15] + +[#_Toc177638875 .anchor]####Appendices to Volume 1 + +== Appendix A – Transaction Examples + +These are the transaction examples for this profile. + +=== A.1 Device Management Information Observation + +The Device Management Information Observation (DMIO) [PCD-15] is the report of an observation of the identification, status, or configuration of a piece of equipment and the reason for the report. + +Observation identifiers of MDCX with a value of zero indicate the MDC and REFID have not yet been officially assigned. Once officially assigned the MDC code will change from zero to its assigned value and the REFID will change to the officially assigned string and implementations shall use values published in the standard + +Identification of some observation identifications (MDC & REFID) are not currently defined in Rosetta Terminology Mapping (RTM) or in IEEE 11073-10101 Nomenclature and so a submission will be required. After values are assigned they are likely to appear in the Rosetta Terminology Mapping Management System (RTMMS) prior to being balloted for an update to the standard. Once assigned official values implementations shall use the assigned values. + +The equipment name shall be in a separate OBX segment occurrence with an observation containment identifying MDC/REFID in OBX-3 (0^MDCX_LS_ATTR_NAME^MDC is proposed until an RTMMS defined value is available) with the equipment name as the observation value in OBX-5 Observation Value. + +The following example is for a PCD-15 message for an infusion pump. + +MSH|^~\&|Device Vendor^001A010000000001^EUI-64||Device Customer||20150119221713-0000||ORU^R44^ORU_R44|1421727433|P|2.6|||AL|NE||UNICODE UTF-8|en^English^ISO639||IHE_PCD_015^IHE PCD^1.3.6.1.4.1.19376.1.6.1.15.1^ISO + +OBR|1|2000101^Medfusion 4000^001A010000000001^EUI-64|2000101^Medfusion 4000^001A010000000001^EUI-64|69135^MDC_OBS_MEM^MDC |||20150119221713-0000 + +OBX|1|ST|69985^MDC_DEV_PUMP_INFUS_MDS^MDC|1.0.0.0|||||||F + +OBX|2|ST|67880^MDC_ATTR_ID_MODEL^MDC|1.0.0.1|manufacturer= Device Vendor model=Medfusion 4000||20150119221713-0000||||F + +OBX|3|ST|67972^MDC_ATTR_SYS_ID^MDC|1.0.0.2|2000101^Medfusion 4000^001A010000000001^EUI-64||20150119221713-0000||||F + +OBX|4|CWE|67925^MDC_ ATTR_POWER_STAT^MDC|1.0.0.3|^OFF||20150119221713-0000||||F|||||||2000101^Medfusion 4000^001A010000000001^EUI-64 + +OBX|5|ST|68512^MDC_ATTR_LS_NAME^MDC|LOC|IV Pump 2012078||||||F|||20150127110822.229-0800 + +OBX|6|PL|68513^MDC_ATTR_LS_LOCATION^MDC|LOC|^^^Fraser Health^^^North Building^Main Floor^Nurse Station||||||F|||20150127110822.229-0800||||112213000174^GuardRFID^^L + +OBX|7|NM|68525^MDC_ATTR_LS_COORD_X^MDC|LOC|406|263441^MDC_DIM_CENTI_M^MDC|||||F|||20150127110822.229-0800||||112213000174^GuardRFID^^L + +OBX|8|NM|68526^MDC_ATTR_LS_COORD_Y^MDC|LOC|917|263441^MDC_DIM_CENTI_M^MDC|||||F|||20150127110822.229-0800||||112213000174^GuardRFID^^L + +OBX|9|NM|68527^MDC_ATTR_LS_COORD_Z^MDC|LOC|0|263441^MDC_DIM_CENTI_M^MDC|||||F|||20150127110822.229-0800||||112213000174^GuardRFID^^L + +[#__RefHeading__73_897662812 .anchor]####Volume 3 – Content Modules + +== 5 Namespaces and Vocabularies + +Add to Section 5 Namespaces and Vocabularies + +None + +== 6 Content Modules + +Not applicable. CDA is not being produced. + +== Volume 3 Namespace Additions + +Add the following terms to the IHE Namespace: + +None + +[#__RefHeading__81_897662812 .anchor]####Volume 4 – National Extensions + +Add appropriate Country section. + +== 4 National Extensions + +None at this time diff --git a/CP Work/Balloted Not Incorporated/CP-PCD-152_MEMDMC_Use_of_MDC_OBS_MEM_in_OBR-4_in_PCD-15_03.docx b/Supplement Repos/memdmc/CP/Ballotted Not Incorporated/CP-PCD-152_MEMDMC_Use_of_MDC_OBS_MEM_in_OBR-4_in_PCD-15_03.docx similarity index 100% rename from CP Work/Balloted Not Incorporated/CP-PCD-152_MEMDMC_Use_of_MDC_OBS_MEM_in_OBR-4_in_PCD-15_03.docx rename to Supplement Repos/memdmc/CP/Ballotted Not Incorporated/CP-PCD-152_MEMDMC_Use_of_MDC_OBS_MEM_in_OBR-4_in_PCD-15_03.docx diff --git a/Supplement Repos/memdmc/archived docx/IHE_DEV_Suppl_MEMDMC_Rev1-5_TI_2024-09-19.docx b/Supplement Repos/memdmc/archived docx/IHE_DEV_Suppl_MEMDMC_Rev1-5_TI_2024-09-19.docx new file mode 100644 index 0000000..61e07aa Binary files /dev/null and b/Supplement Repos/memdmc/archived docx/IHE_DEV_Suppl_MEMDMC_Rev1-5_TI_2024-09-19.docx differ diff --git a/Supplement Repos/memls/AsciiDoc Source/extracted-media-memls/media/image1.jpeg b/Supplement Repos/memls/AsciiDoc Source/extracted-media-memls/media/image1.jpeg new file mode 100644 index 0000000..4459cc0 Binary files /dev/null and b/Supplement Repos/memls/AsciiDoc Source/extracted-media-memls/media/image1.jpeg differ diff --git a/Supplement Repos/memls/AsciiDoc Source/memls.adoc b/Supplement Repos/memls/AsciiDoc Source/memls.adoc new file mode 100644 index 0000000..f533b6a --- /dev/null +++ b/Supplement Repos/memls/AsciiDoc Source/memls.adoc @@ -0,0 +1,805 @@ +*Integrating the Healthcare Enterprise* + +image:extracted-media-memls/media/image1.jpeg[IHE_LOGO_for_tf-docs,width=171,height=88] + +*IHE Devices* + +*Technical Framework Supplement* + +*PCD Program* + +*Medical Equipment Management* + +*Location Services* + +*(MEMLS)* + +*Rev. 1.5 – Trial Implementation* + +Date: September 19, 2024 + +Author: IHE Devices Technical Committee + +Email: pcd@ihe.net + +*Please verify you have the most recent version of this document.* See http://ihe.net/Technical_Frameworks/[here] for Trial Implementation and Final Text versions and http://ihe.net/Public_Comment/[here] for Public Comment versions. + +*Foreword* + +This is a supplement to the IHE Devices Technical Framework. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks. + +This supplement is published on September 19, 2024 for trial implementation and may be available for testing at subsequent IHE Connectathons. The supplement may be amended based on the results of testing. Following successful testing it will be incorporated into the Devices Technical Framework. Comments are invited and can be submitted at https://www.ihe.net/DEV_Public_Comments/[https://www.ihe.net/DEV_Public_Comments]. + +This supplement describes changes to the existing technical framework documents. + +“Boxed” instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume. + +Amend Section X.X by the following: + +Where the amendment adds text, make the added text *[.underline]#bold underline#*. Where the amendment removes text, make the removed text *[line-through]#bold strikethrough#*. When entire new sections are added, introduce with editor’s instructions to “add new text” or similar, which for readability are not bolded or underlined. + +General information about IHE can be found at http://www.ihe.net/[IHE.net]. + +Information about the IHE Devices domain can be found at https://www.ihe.net/ihe_domains/[IHE Domains]. + +Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at https://www.ihe.net/resources/profiles/[Profiles] and https://www.ihe.net/about_ihe/ihe_process/[IHE Processes]. + +The current version of the IHE Devices Technical Framework can be found at https://profiles.ihe.net/DEV/[Devices Technical Framework]. + +CONTENTS + +link:#introduction-to-this-supplement[Introduction to this Supplement link:#introduction-to-this-supplement[5]] + +link:#open-issues-and-questions[Open Issues and Questions link:#open-issues-and-questions[5]] + +link:#closed-issues[Closed Issues link:#closed-issues[6]] + +link:#history-of-document-changes[History of Document Changes link:#history-of-document-changes[6]] + +link:#ihe-technical-frameworks-general-introduction[IHE Technical Frameworks General Introduction link:#ihe-technical-frameworks-general-introduction[7]] + +link:#copyright-licenses[9 Copyright Licenses link:#copyright-licenses[7]] + +link:#trademark[10 Trademark link:#trademark[7]] + +link:#ihe-technical-frameworks-general-introduction-appendices[IHE Technical Frameworks General Introduction Appendices link:#ihe-technical-frameworks-general-introduction-appendices[8]] + +link:#_Toc177639746[Appendix A – Actors link:#_Toc177639746[8]] + +link:#_Toc177639747[Appendix B – Transactions link:#_Toc177639747[9]] + +link:#_Toc177639748[Appendix D – Glossary link:#_Toc177639748[9]] + +link:#_Toc177639749[*Volume 1 – Profiles link:#_Toc177639749[11]*] + +link:#copyright-licenses-1[Copyright Licenses link:#copyright-licenses-1[11]] + +link:#domain-specific-additions[Domain-specific additions link:#domain-specific-additions[11]] + +link:#x-medical-equipment-management-location-services-memls-profile[X Medical Equipment Management Location Services (MEMLS) Profile link:#x-medical-equipment-management-location-services-memls-profile[11]] + +link:#x.1-memls-actors-transactions-and-content-modules[X.1 MEMLS Actors, Transactions, and Content Modules link:#x.1-memls-actors-transactions-and-content-modules[11]] + +link:#x.1.1-actor-descriptions-and-actor-profile-requirements[X.1.1 Actor Descriptions and Actor Profile Requirements link:#x.1.1-actor-descriptions-and-actor-profile-requirements[12]] + +link:#x.1.1.1-location-observation-reporter-lor[X.1.1.1 Location Observation Reporter (LOR) link:#x.1.1.1-location-observation-reporter-lor[12]] + +link:#x.1.1.2-location-observation-consumer-loc[X.1.1.2 Location Observation Consumer (LOC) link:#x.1.1.2-location-observation-consumer-loc[13]] + +link:#x.2-memls-actor-options[X.2 MEMLS Actor Options link:#x.2-memls-actor-options[13]] + +link:#x.3-memls-required-actor-groupings[X.3 MEMLS Required Actor Groupings link:#x.3-memls-required-actor-groupings[13]] + +link:#x.4-memls-overview[X.4 MEMLS Overview link:#x.4-memls-overview[13]] + +link:#x.4.1-concepts[X.4.1 Concepts link:#x.4.1-concepts[13]] + +link:#x.4.2-use-cases[X.4.2 Use Cases link:#x.4.2-use-cases[14]] + +link:#x.4.2.1-use-case-1-communication-of-location-observations-in-conjunction-with-other-non-location-related-transactions[X.4.2.1 Use Case #1: Communication of location observations in conjunction with other non-location related transactions link:#x.4.2.1-use-case-1-communication-of-location-observations-in-conjunction-with-other-non-location-related-transactions[14]] + +link:#x.4.2.1.1-location-added-to-other-observations-use-case-description[X.4.2.1.1 Location Added to Other Observations Use Case Description link:#x.4.2.1.1-location-added-to-other-observations-use-case-description[14]] + +link:#x.4.2.1.2-location-added-to-other-observations-process-flow[X.4.2.1.2 Location Added to Other Observations Process Flow link:#x.4.2.1.2-location-added-to-other-observations-process-flow[14]] + +link:#x.4.2.2-use-case-2-communication-of-location-observations-in-conjunction-with-ls-specific-events[X.4.2.2 Use Case #2: Communication of location observations in conjunction with LS specific events link:#x.4.2.2-use-case-2-communication-of-location-observations-in-conjunction-with-ls-specific-events[15]] + +link:#x.4.2.2.1-location-event-observations-use-case-description[X.4.2.2.1 Location Event Observations Use Case Description link:#x.4.2.2.1-location-event-observations-use-case-description[15]] + +link:#x.4.2.2.2-location-event-observations-process-flow[X.4.2.2.2 Location Event Observations Process Flow link:#x.4.2.2.2-location-event-observations-process-flow[15]] + +link:#x.5-memls-security-considerations[X.5 MEMLS Security Considerations link:#x.5-memls-security-considerations[15]] + +link:#x.6-memls-cross-profile-considerations[X.6 MEMLS Cross Profile Considerations link:#x.6-memls-cross-profile-considerations[16]] + +link:#_Toc177639770[*Volume 2 – Transactions link:#_Toc177639770[17]*] + +link:#report-location-observation-rlo-pcd-16[3.16 Report Location Observation (RLO) [PCD-16] link:#report-location-observation-rlo-pcd-16[17]] + +link:#scope[3.16.1 Scope link:#scope[17]] + +link:#actor-roles[3.16.2 Actor Roles link:#actor-roles[17]] + +link:#_Toc177639774[3.16.3 Referenced Standards link:#_Toc177639774[18]] + +link:#messages[3.16.4 Messages link:#messages[19]] + +link:#report-location-observation-rlo-pcd-16-1[3.16.4.1 Report Location Observation (RLO) [PCD-16] link:#report-location-observation-rlo-pcd-16-1[19]] + +link:#ls-observation-types[3.16.4.1.1 LS Observation Types link:#ls-observation-types[20]] + +link:#hl7-conformance-statement[3.16.4.1.2 HL7 Conformance Statement link:#hl7-conformance-statement[20]] + +link:#report-location-observation-pcd-16-orur45oru_r45-static-definition[3.16.4.1.3 Report Location Observation [PCD-16] (ORU^R45^ORU_R45) Static Definition link:#report-location-observation-pcd-16-orur45oru_r45-static-definition[21]] + +link:#trigger-events[3.16.4.1.4 Trigger Events link:#trigger-events[22]] + +link:#message-semantics[3.16.4.1.5 Message Semantics link:#message-semantics[23]] + +link:#proposed-additions-to-ieee-11073-10101[3.16.4.1.5.1 Proposed additions to IEEE 11073-10101 link:#proposed-additions-to-ieee-11073-10101[24]] + +link:#expected-actions[3.16.4.1.6 Expected Actions link:#expected-actions[26]] + +link:#security-considerations[3.16.5 Security Considerations link:#security-considerations[26]] + +link:#volume-2-namespace-additions[Volume 2 Namespace Additions link:#volume-2-namespace-additions[26]] + +link:#_Toc177639786[Appendices to Volume 2 link:#_Toc177639786[27]] + +link:#appendix-a-transaction-examples[Appendix A – Transaction Examples link:#appendix-a-transaction-examples[27]] + +link:#a.1-report-location-observation-for-equipment[A.1 Report Location Observation for equipment link:#a.1-report-location-observation-for-equipment[27]] + +link:#a.2-report-location-observation-for-people[A.2 Report Location Observation for people link:#a.2-report-location-observation-for-people[28]] + +link:#_Toc177639790[*Volume 3 – Content Modules link:#_Toc177639790[30]*] + +link:#namespaces-and-vocabularies[5 Namespaces and Vocabularies link:#namespaces-and-vocabularies[30]] + +link:#content-modules[6 Content Modules link:#content-modules[30]] + +link:#_Toc177639793[Volume 3 Namespace Additions link:#_Toc177639793[30]] + +link:#_Toc177639794[*Volume 4 – National Extensions link:#_Toc177639794[31]*] + +link:#national-extensions[4 National Extensions link:#national-extensions[31]] + +== Introduction to this Supplement + +This supplement affects volumes 1 and 2 of the Devices Technical Framework. The supplement adds a new profile, new actors, new triggers, and a new transaction. This supplement defines a profile for the communication of equipment and people location information in the absence of patient observations, alerts, or event notifications. + +The IHE Working Group (WG) that created and maintains this profile (PCD MEMLS WG) is aware of IEEE WG P1847 Location-Based Services (LBS) for Healthcare. The results of ongoing interactions with this IEEE WG are expected to impact this profile from time to time. Additionally, some content from this profile should be assumed to be available for utilization in the deliverables of the IEEE WG. + +=== Open Issues and Questions + +Staff location tracking is about more than the technology which can accomplish it. This effort will focus predominately on equipment location, but will provide a means of communicating location information of people. Enumerating all that can be accomplished with that information and all of the issues around those accomplishments is outside the scope of this effort. + +Identification of some observation identifications (MDC & REFID) are not be currently defined in Rosetta Terminology Mapping (RTM) or in IEEE 11073-10101 Nomenclature and so a submission will be required. After values are assigned they are likely to appear in the Rosetta Terminology Mapping Management System (RTMMS) prior to being balloted for an update to the standard. Once assigned official values implementations shall use the assigned values. + +A unique to this profile HL7 v2 message trigger has been granted by HL7 v2 Orders and Observations to replace current use of trigger value R01. This profile utilizes unsolicited observations and therefore MSH-9-1 Message Code shall remain ORU. The HL7 granted trigger value is R45, is queued to first appear in a v 2.9.x release of HL7 v2 and replaces R01 in the MSH-9 Message Type field in both MSH-9-2 Trigger and MSH-9-3 Message Structure components in examples and references within this document have been updated accordingly. This trigger change while impacting to existing products, test tools, and deployments will allow transactions of this profile to utilize a message structure unique to this profile which will permit discontinuance of use of the message structure associated with R01. This change will allow transactions of this profile to exclude the R01 structure required HL7 message segments associated with electronic patient healthcare information (ePHI) contained in the PID Patient Identification and PV1 Patient Visit segments. Observation producer and consumer actors associated with this profile do not make use of and do not administer ePHI. Removal of ePHI message content which is not required by this profile assures patient confidentiality and avoids transaction consuming actors from requiring a HIPAA (Health Insurance Portability and Accountability Act of 1996) Business Associate agreement. + +When copying OBX instances from consumed transactions of this profile to reporter transactions of other profiles, such as DEC, IPEC, ACM, etc., the dotted notation values in OBX-4 should bear scrutiny for hierarchical conflicts with OBX-4 values of OBX instances associated with the base reporter content into which the OBX instances of this profile are being copied. + +=== Closed Issues + +Communication of the same information that this profile communicates as observations in conjunction with the data, alert, and event use cases associated with existing PCD profiles can be accomplished using the observation documentation found in this profile as additional observations to existing transactions in association with existing actors without the requirement for vendor adoption of this new profile. The justification for this additional profile is the definition of a new actor type (LS) which is distinct from existing actors as well as the trigger condition which is unrelated to any device associated patient. + +Other methods for communication of location information exist in the operating environment (SNMP, vendor proprietary SOAP/XML, etc.) today, are expected to continue to exist, but are not expected to integrate with medical device data communication. + +=== History of Document Changes + +This section provides a brief summary of changes and additions to this document. + +[width="100%",cols="15%,14%,71%",options="header",] +|=== +|Date |Document Revision |Change Summary +|2024-SEP |1.5 a| +Updated for approved CPs, housekeeping corrections + +[width="100%",cols="18%,19%,63%",options="header",] +!=== +!CP # !CP Approval Date !CP Title +!DEV-004 !2024-06-12 !MEM LS Trigger and Template +!=== + +|2023-04-07 |1.4 a| +Updated for approved CPs, housekeeping corrections, and replacing MDCXs with allocated MDCs and REFIDs. + +The following CPs were integrated. + +[width="100%",cols="15%,22%,63%",options="header",] +!=== +!CP # !CP Approval Date !CP Title +!112 !2015-02-26 !Move equipment name from OBX-18 to OBX-5 +!120 !2015-03-06 !Clarification of Observation Result Status OBX-11 as F +!160 !2022-01-07 !MEM LS Multiple Location Observations, PL Clarity +!=== + +|2017-11-09 |1.3 |Updated for approved CPs, housekeeping corrections, and explanation that MDCs and REFIDs need to be standardized and that they will appear first in RTMMS. +|2015-10-14 |1.2 |Updated for approved CPs and housekeeping corrections. +|=== + +== IHE Technical Frameworks General Introduction + +The https://profiles.ihe.net/GeneralIntro[IHE Technical Frameworks General Introduction] is shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to this document where appropriate. + +== Copyright Licenses + +IHE technical documents refer to, and make use of, a number of standards developed and published by several standards development organizations. Please refer to the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-9.html[Section 9 - Copyright Licenses] for copyright license information for frequently referenced base standards. Information pertaining to the use of IHE International copyrighted materials is also available there. + +== Trademark + +IHE^®^ and the IHE logo are trademarks of the Healthcare Information Management Systems Society in the United States and trademarks of IHE Europe in the European Community. Please refer to the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-10.html[Section 10 - Trademark] for information on their use. + +== IHE Technical Frameworks General Introduction Appendices + +The https://profiles.ihe.net/GeneralIntro/index.html[IHE Technical Framework General Introduction Appendices] are components shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to these documents where appropriate. + +Update the following appendices to the General Introduction as indicated below. Note that these are *not* appendices to this domain’s Technical Framework (TF-1, TF-2, TF-3 or TF-4) but rather, they are appendices to the IHE Technical Frameworks General Introduction located https://profiles.ihe.net/GeneralIntro/index.html[here]. + +*NEW: REQUIRED APPROVAL OF ACTORS, TRANSACTIONS and TERMS -* To avoid duplication and ensure consistency across domains, all *new or modified* actors, transactions and glossary terms need approval by IHE’s Domain Coordination Committee (DCC) before they are published in a trial implementation supplement. Please see https://wiki.ihe.net/index.php/Approval_Process_for_IHE_Actors,_Transactions_and_Glossary_Terms[this Wiki page] for additional guidance and links to the forms for approval submission. + +== https://profiles.ihe.net/GeneralIntro/ch-A.html[[#_Toc177639746 .anchor]####Appendix A] – Actors + +Add the following *new or modified* actors to the https://profiles.ihe.net/GeneralIntro/ch-A.html[IHE Technical Frameworks General Introduction Appendix A]: + +The Location Observation Reporter (LOR) produces observations. + +The Location Observation Consumer (LOC) consumes observations. + +[width="100%",cols="40%,60%",] +|=== +|Actor |Definition +|Location Observation Reporter (LOR) |The profile actor that sends Location Services observations of location for devices or people and data from Location Services tags +|Location Observation Consumer (LOC) |The profile actor that receives Location Services observations +|=== + +The Location Observation Reporter (LOR) is a new and distinct observation source actor and is likely to be a Location Services system (LS) also recognized by the underlying technology used for equipment and people tracking, such as Radio Frequency Identification (RFID) or Real Time Location Services (RTLS). But it may also be an actor in a different profile (DEC DOR, ACM AR, IPEC DOR), assuming the location tracking and reporting capability is embedded into the medical device or the location observation is merged with the medical device data in a gateway system prior to it being sent to the observation consumer. The Location Observation Consumer (LOC) may also be an actor in a different profile (DEC DOC, ACM AM, IPEC DOC). + +== https://profiles.ihe.net/GeneralIntro/ch-B.html[[#_Toc177639747 .anchor]####Appendix B] – Transactions + +Add the following *new or modified* transactions to the https://profiles.ihe.net/GeneralIntro/ch-B.html[IHE Technical Frameworks General Introduction Appendix B]: + +Report Location Observation (RLO) (from LOR to LOC) + +[width="100%",cols="37%,63%",options="header",] +|=== +|New (or modified) Transaction Name and Number |Definition +|Report Location Observation [PCD-16] |If the location observation information is sourced from an external to device tag and reporting system, then the device to which it is attached has the potential of being unaware of its presence and would likely not contain device associated patient information. Then, the observation will be sourced by the LS and not the medical device. This transactions contains an observation of the location of a device or person or information about the Location Services tag, such as environmental (temperature, humidity, gases, etc.) or operator interactions (buttons, pulls, accelerometers, etc.). +|=== + +== https://profiles.ihe.net/GeneralIntro/ch-D.html[Appendix D] – Glossary + +Add the following *new or modified* glossary terms to the https://profiles.ihe.net/GeneralIntro/ch-D.html[IHE Technical Frameworks General Introduction Appendix D]: + +[width="100%",cols="28%,42%,14%,16%",options="header",] +|=== +|New (or modified) Glossary Term |Definition |Synonyms a| +Acronym/ + +Abbreviation + +|Computerized Maintenance Management System |This is the system which the hospital makes use of to maintain its inventory of medical devices, their identification, their status, their software, firmware, and hardware versioning information and history. This is a system for which reception of device location observation is well suited as a means of identifying the last known location of equipment in need of servicing, repairs, or version upgrades. | |CMMS +|Global Positioning System |This is the system of orbiting satellites that are constantly broadcasting extremely high accuracy time information, combined with ubiquitous receivers and software associated with the receivers that upon correlation of the received data can identify with reasonably high accuracy the location of the receiver in 3D space by latitude, longitude, and altitude. | |GPS +|Health Insurance Portability and Accountability Act of 1996 |The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a federal law that required the creation of national standards to protect sensitive patient health information from being disclosed without the patient’s consent or knowledge. The US Department of Health and Human Services (HHS) issued the HIPAA Privacy Rule to implement the requirements of HIPAA. The HIPAA Security Rule protects a subset of information covered by the Privacy Rule. See https://www.cdc.gov/phlp/publications/topic/hipaa.html. | |HIPAA +|Location Services |This is a collection of software applications and services which utilize tag tracking information to provide the last known location of the tags as well as any environmental or operator interactions with the tags. | |LS +|National Marine Electronics Association |This is a worldwide, self-sustaining organization with the commitment to enhance the technology and safety of electronics used in marine applications. | |NMEA +|Radio Frequency Identification |This is the technology whereby tags will transmit their unique identification either periodically (active) or when energized by an energy field (passive). This identification transmission can be correlated by multiple receives to identify the location of the tag. | |RFID +|Real Time Location Services |This is an aspect of Location Services whereby the last known location of devices or people can be communicated to other systems. | |RTLS +|=== + +[#_Toc177639749 .anchor]####Volume 1 – Profiles + +=== Copyright Licenses + +Add the following to the IHE Technical Frameworks General Introduction Copyright section: + +NA + +=== Domain-specific additions + +None + +Add Section X + +== X Medical Equipment Management Location Services (MEMLS) Profile + +Existing profile transaction observation information does not include detailed device and people location identification which can be sourced by embedded location sensing components or through location sensing tags external to equipment and these tags can also provide additional information such as button presses and environmental information such as temperature and humidity. Additionally, there are no defined actors or transactions for providing location information from other than medical devices to other than an EMR or an alert manager. + +Specific triggers, transactions, and source actors in existing profiles do not exist for the sole purpose of communication of location information in the absence of patient observations, alerts, or event notifications. The absence of the communication of this information outside of patient observations, alerts, or event notifications reduces the effectiveness of Location Services (LS) solutions and impacts the effectiveness of people interactions with equipment and systems by not providing for location information or location specific events. + +This profile is a combination of profile types as it defines workflow through use case specification and transport through its described use of the HL7 v2 and IEEE 11073 standards for information communication. + +=== X.1 MEMLS Actors, Transactions, and Content Modules + +This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at https://profiles.ihe.net/GeneralIntro/index.html. + +Figure X.1-1 shows the actors directly involved in the MEMLS Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines. Actors which have a mandatory grouping are shown in conjoined boxes. + +Figure X.1-1: MEMLS Actor Diagram + +Table X.1-1 lists the transactions for each actor directly involved in the MEMLS Profile. To claim compliance with this profile, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”). + +Table X.1-1: MEMLS Profile - Actors and Transactions + +[width="100%",cols="19%,23%,22%,36%",options="header",] +|=== +|Actors |Transactions |Optionality |Reference +|LOR |RLO [PCD-16] |R |DEV TF-2: 3.16 +|LOC |RLO [PCD-16] |R |DEV TF-2: 3.16 +|=== + +==== X.1.1 Actor Descriptions and Actor Profile Requirements + +Most requirements are documented in Transactions (Volume 2) and Content Modules (Volume 3). This section documents any additional requirements on profile’s actors. + +===== X.1.1.1 Location Observation Reporter (LOR) + +The Location Observation Reporter (LOR) may also be an observation transaction sending actor in other IHE Devices profiles, such as a DEC DOR, an ACM AR, an IPEC DOR, or a MEMDMC DMIR. This could be the case if the location tracking tag is either embedded in the sending actor or if the tag is external and a gateway system is being used to merge the location information with observations associated with other IHE profiles. If the tag is external the medical device may have no awareness of its presence or if the observations are unique to location services and are not associated with patients. The location services specific nature of the observations produced by the Location Observation Reporter is the justification for this unique profile. + +===== X.1.1.2 Location Observation Consumer (LOC) + +It is highly likely that the Location Observation Consumer may also be an observation transaction receiving actor in other IHE Devices profiles. If the observation is simply to be recorded it is likely to be a DEC DOC or IPEC DOC Actor. If the observation is to be acted upon, it is likely to be an ACM AM Actor. If the location observation is to be used for equipment management, the LOC Actor is likely to be a MEMDMC DMIC Actor (a CMMS). + +=== X.2 MEMLS Actor Options + +Options that may be selected for each actor in this profile, if any, are listed in the Table X.2-1. Dependencies between options when applicable are specified in notes. + +Table X.2-1: MEMLS - Actors and Options + +[width="100%",cols="20%,36%,44%",options="header",] +|=== +|Actor |Option Name |Reference +|LOR |No options defined |-- +|LOC |No options defined |-- +|=== + +=== X.3 MEMLS Required Actor Groupings + +There are no required actor groupings. + +=== X.4 MEMLS Overview + +MEM LS is focused on getting location tracking or tag related observations into medical records and into equipment management systems. + +==== X.4.1 Concepts + +Location information is pertinent to medical device observations as it provides a means of locating the patient currently associated with that equipment. This can be additional observation information added to existing transactions without the use of this profile. This profile focuses on those uses of location tracking information or tag associated information independent of any patient currently associated with the equipment, such as for equipment management, and tag auxiliary information such as button presses or environmental observations like temperature and humidity. + +If the end result of receipt of such information is the generation of Report Alert [PCD-04] transactions in association with the ACM Profile then the sending system is considered to be an AR with additional types of alerts and observations. + +==== X.4.2 Use Cases + +===== X.4.2.1 Use Case #1: Communication of location observations in conjunction with other non-location related transactions + +This is the addition of location observations in the same transaction with non-location related transactions, such as DEC [PCD-01], ACM [PCD-04], IPEC [PCD-10], and MEMDMC [PCD-15]. + +====== X.4.2.1.1 Location Added to Other Observations Use Case Description + +This presumes that the reporting piece of equipment or system is location aware and so has the location information to include in with its other observations. This can be accomplished either by embedding the location tracking capability into the equipment or by using a gateway external to the device and to the location tracking system to merge the information into a single device observation plus location observation message. + +====== X.4.2.1.2 Location Added to Other Observations Process Flow + +A producer (DEC DOR or IPEC DOR or ACM AR or MEMDMC DMIR) is producing an observation (evidentiary data, alert, or event) and is location aware and includes location as an observation in with the rest of the observations. The device or system is made location aware either through an embedded location tag or by querying an external system that is aware of the location of a tag physically external to the device or system producing the observation. Such transactions are outside the scope of this profile and are addressed by the existing DEC, ACM, IPEC, and MEMDMC Profiles. + +Figure X.4.2.1.2-1: Basic Process Flow in MEMLS Profile + +Main Flow: + +An observation, alert, or event has occurred and a device or system will be producing a profile related transaction [(PCD-01], [PCD-04], [PCD-10], or [PCD-15]). The device or system is location aware and will include location as an additional observation in the transaction. + +===== X.4.2.2 Use Case #2: Communication of location observations in conjunction with LS specific events + +This is the addition of location observations in the same transactions with location related transactions, such as DEC [PCD-01] and ACM [PCD-04]. These are LS specific and not patient specific. + +====== X.4.2.2.1 Location Event Observations Use Case Description + +This presumes that the reporting piece of equipment or system is location aware and so has the location information to include in with its other observations. + +====== X.4.2.2.2 Location Event Observations Process Flow + +A producer (DEC DOR or ACM AR or IPEC DOR or MEMDMC DMIR) is producing an LS specific observation (evidentiary data, alert, or event) and is location aware and includes location as an observation in with the rest of the observations. The device or system is made location aware either through an embedded location tag or by querying an external system that is aware of the location of a tag physically external to the device or system producing the observation. + +For backward compatibility with existing applications that only look for and process a single device single location observation per MEM LS Report Location Observation (RLO) [PCD-16] transaction, if multiple location observations for the same device are communicated in a single Report Location Observation (RLO) [PCD-16] transaction the first observation shall be the most fully resolved, meaning having the most non-empty components of the Person Location (PL) datatype, with lesser resolved location observations following it in order of decreasing completeness of resolution. See the note within the PL datatype definition in HL7 version 2.6 chapter 2A Control (DataTypes) page 53 which spells out PL component ordering. + +Figure X.4.2.2.2-1: Basic Process Flow in MEMLS Profile + +=== X.5 MEMLS Security Considerations + +During the Profile development there were no unusual security or privacy concerns identified. There are no mandatory security controls but the implementer is encouraged to use the underlying security and privacy profiles from ITI that are appropriate to the transports such as the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk assessment, following ISO 80001, will determine the actual security and safety controls employed. + +=== X.6 MEMLS Cross Profile Considerations + +An LOR is likely to also be a DEC DOR, an IPEC DOR, an ACM AR, or MEMDMC DIOR. There is no grouping required. + +An LOC is likely to also be a DEC DOC, an IPEC DOC, an ACM AM, or MEMDMC DIOC. There is no grouping required. + +[#_Toc177639770 .anchor]####Volume 2 – Transactions + +Add Section 3.16 + +=== 3.16 Report Location Observation (RLO) [PCD-16] + +==== 3.16.1 Scope + +This transaction is used to report location observations for equipment or people. + +==== 3.16.2 Actor Roles + +The LOR sends the RLO to the LOC. + +Figure 3.16.2-1: Use Case Diagram + +The roles in this transaction are defined in the following table and may be played by the actors shown here: + +Table 3.16.2-1: Actor Roles + +[width="100%",cols="19%,81%",] +|=== +|*Role:* |Producer +|*Actor(s):* a| +The following actors may play the role of Producer: + +____ +Location Observation Reporter (LOR) +____ + +|*Role:* |Consumer +|*Actor(s):* a| +The following actors may play the role of Consumer: + +____ +Location Observation Consumer (LOC) +____ + +|=== + +==== 3.16.3 Referenced Standards + +HL7 v2.6, Chapter 7 Observations and v2.7, Chapter 7 Observations for the PRT segment, transitioning to v2.9.x once published for new trigger/template. + +IEEE 11073-10101, minimally version B, with additional MDC/REFID values not yet in the standard (as identified by MDCX indicated value of zero and the interim REFID values). + +Identification of some observation identifications (MDC & REFID) might not be currently defined in Rosetta Terminology Mapping (RTM) or in IEEE 11073-10101 Nomenclature in which case a submission will be required. These are maintained external to this profile and thus have a low probability of new change proposals to this profile. After values are assigned, they appear in the current version of Rosetta Terminology Mapping Management System (RTMMS) prior to being balloted for an update to the standard. Once assigned, official values implementations shall use the assigned values. + +Below is a mapping table with an indication as to whether or not the REFID string changed from the trial to the allocated values. To reduce transcription errors, table content has been kept to a minimum. For additional details, such as value descriptions, units of measure, partition codes, and enumerations, refer to the IEEE 11073-10101 standard (normative and balloted versions) or RTMMS. + +Table 3.16.3-1: IEEE Nomenclature Mapping from preliminary to assigned + +[width="100%",cols="45%,43%,12%",options="header",] +|=== +|Trial Values |Allocated Values |Changed +|0^MDCX_EVT_LS_DEVICE |203776^MDC_EVT_LS_DEVICE^MDC |N +|0^MDCX_EVT_LS_PERSON |203778^MDC_EVT_LS_PERSON^MDC |N +|0^MDCX_LS_ATTR_NAME^MDC |68512^MDC_ATTR_LS_NAME^MDC |Y +|0^MDCX_LS_ATTR_LOCATION^MDC |68513^MDC_ ATTR_LS_LOCATION^MDC |Y +|0^MDCX_LS_ATTR_ADDRESS^MDC |68514^MDC_ATTR_LS_ADDRESS^MDC |Y +|none |68515^MDC_ATTR_LS_PHASE^MDC |N +|0^MDCX_LS_ATTR_REF_NAME^MDC |68517^MDC_ATTR_LS_REF_NAME^MDC |Y +|none |68518^MDC_ATTR_LS_REF_GPS^MDC |N +|none |68519^MDC_ATTR_LS_REF_GPS_LAT^MDC |N +|none |68520^MDC_ATTR_LS_REF_GPS_LON^MDC |N +|none |68521^MDC_ATTR_LS_REF_GPS_ALT^MDC |N +|none |68522^MDC_ATTR_LS_REF_GPS_BEARING^MDC |N +|none |68523^MDC_ATTR_LS_REF LIMITS^MDC |N +|none |68524^MDC_ATTR_LS_COORD_XYZ^MDC |N +|0^MDCX_LS_ATTR_COORD_X^MDC |68525^MDC_ATTR_LS_COORD_X^MDC |Y +|0^MDCX_LS_ATTR_COORD_Y^MDC |68526^MDC_ATTR_LS_COORD_Y^MDC |Y +|0^MDCX_LS_ATTR_COORD_Z^MDC |68527^MDC_ATTR_LS_COORD_Z^MDC |Y +|none |68528^MDC_ATTR_LS_COORD_XYZ_ACCY^MDC |N +|0^MDCX_LS_ATTR_COORD_X_ACCURACY^MDC |68529^MDC_ATTR_LS_COORD_X_ACCY^MDC |Y +|0^MDCX_LS_ATTR_COORD_Y_ACCURACY^MDC |68530^MDC_ATTR_LS_COORD_Y_ACCY^MDC |Y +|0^MDCX_LS_ATTR_COORD_Z_ACCURACY^MDC |68531^MDC_ATTR_LS_COORD_Z_ACCY^MDC |Y +|none |68532^MDC_ATTR_GPS_COORDINATES |N +|0^MDCX_GPS_ATTR_LATITUDE^MDC |68533^MDC_ATTR_GPS_LAT^MDC |Y +|0^MDCX_GPS_ATTR_LONGITUDE^MDC |68534^MDC_ATTR_GPS_LON^MDC |Y +|0^MDCX_GPS_ATTR_ACCURACY |68535^MDC_ATTR_GPS_COORD_ACCY^MDC |N +|none |68536^MDC_ATTR_GPS_LAT_ACCY^MDC |N +|none |68537^MDC_ATTR_GPS_LON_ACCY^MDC |N +|0^MDCX_GPS_ATTR_ALTITUDE^MDC |68538^MDC_ATTR_GPS_ALT^MDC |Y +|none |68539^MDC_ATTR_GPS_ALT_ACCY^MDC |N +|0^MDCX_GPS_ATTR_HEADING^MDC |68540^MDC_ATTR_GPS_HEADING^MDC |Y +|0^MDCX_GPS_ATTR_PITCH^MDC |68541^MDC_ATTR_GPS_PITCH^MDC |Y +|0^MDCX_GPS_ATTR_SPEED^MDC |68542^MDC_ATTR_GPS_SPEED^MDC |Y +|none |69135^MDC_OBS_MEM^MDC |N +|=== + +==== 3.16.4 Messages + +Figure 3.16.4-1: Interaction Diagram + +===== 3.16.4.1 Report Location Observation (RLO) [PCD-16] + +The observations are mapped to OBX (equipment) and PRT (people or equipment) segments and contained under the OBX segment which identifies the observation type (person or equipment). + +A single transaction should report about one piece of equipment or one person. + +More than one sending actor instance can send to the same receiving actor instance. + +For backward compatibility with existing applications that only look for and process a single device single location observation per MEM LS Report Location Observation (RLO) [PCD-16] transaction, if multiple location observations for the same device are communicated in a single Report Location Observation (RLO) [PCD-16] transaction the first observation shall be the most fully resolved. + +====== 3.16.4.1.1 LS Observation Types + +Location observations can be reported in one or more types. + +* Named Location (hospital named hierarchical location or simple name string) +* Base + (X/Y/Z) offset plus accuracy indications +* GNSS/GPS plus accuracy indications + +Named locations are preferred for communication of a location to a person. Base + offset is used to communicate location to another LS system for moving pushpins on active maps or floor layouts. GNSS/GPS is good for absolute location retrospective analysis or for locations outside structures. + +The Base reference for base + offset location observations is typically a mutually agreed base map, such as an electronic architectural diagram file for an area within a building, such as a care unit on a floor within a hospital building. + +For backward compatibility with existing applications that only look for and process a single device single location observation per MEM LS Report Location Observation (RLO) [PCD-16] transaction, if multiple location observations for the same device are communicated in a single Report Location Observation (RLO) [PCD-16] transaction the first observation shall be the most fully resolved, meaning having the most non-empty components of the Person Location (PL) datatype, with lesser resolved location observations following it in order of decreasing completeness of resolution. See the note within the PL datatype definition in HL7 version 2.6 chapter 2A Control (DataTypes) page 53 which spells out PL component ordering. + +====== 3.16.4.1.2 HL7 Conformance Statement + +The conformance statement for this interaction described below is adapted from HL7 version 2.6 with use of the Participation Information (PRT) segment from HL7 version 2.7. + +Table 3.16.4.1.2-1: Report Location Observation [PCD-16] Transaction Conformance + +[width="100%",cols="35%,65%",options="header",] +|=== +|Publication ID: |R45 +|Type: |Unsolicited +|Publication Name: |IHEPCD-16ReportLocationObservation +|Trigger: |See Section 3.16.4.1.4 Trigger Events +|Mode: |Immediate +|Response: |ORU^R45^ORU_R45 +|Characteristics: |Sends defined location observation data +|Purpose: |Report Location Observation from LOR to LOC +|Based on Segment Pattern: |R45 +|=== + +====== 3.16.4.1.3 Report Location Observation [PCD-16] (ORU^R45^ORU_R45) Static Definition + +The Report Location Observation [PCD-16] message is used to communicate location observation data from a Location Observation Reporter (LOR) to a Location Observation Consumer (LOC). + +Common HL7 segments are defined in DEV TF-2: Appendix B. Sections below discuss considerations specific to [PCD-16]. + +Figure 3.16.4.1.3-1: Basic Process Flow for MEMLS Profile (reference) + +Table 3.16.4.1.3-1: ORU^R45^ORU_R45 HL7 Attribute Table + +[width="100%",cols="13%,39%,16%,15%,17%",options="header",] +|=== +|Segment |ORU Message |Usage |Card. |HL7 Ref +|MSH |Message Header Segment |R |[1..1] |2.15.9 +|OBR |Observation Request Segment |R |[1..n] |7.4.1 +|OBX |Observation Result Segment |R |[1..n] |7.4.2 +|[PRT] |Participation Information Segment |O |[0..n] Note 1 |7.4.4 (V2.7) +|=== + +Note 1: Use of PRT is required for communicating the location of people. If operating in a backward compatible manner for equipment location observations this can be accomplished using OBX-18 Equipment Instance Identifier instead of the PRT segment. + +Table 3.16.4.1.3-2: ORU^R45^ORU_R45 Static Definition + +[width="100%",cols="47%,53%",options="header",] +|=== +|ORU^R45^ORU_R45 |Device Management Information Observation Message +|MSH |Message Header +|[\{SFT}] |Software Segment +|\{ |--- REPORT LOCATION OBSERVATION begin +|\{ |--- LOCATION_OBSERVATION begin +|OBR |Location Observation Identification +|\{ |--- OBSERVATION begin +|\{OBX} |Location observations relative to OBR +|[PRT] |Participation identifies person or equipment +|} |--- OBSERVATION end +|} |--- LOCATION_OBSERVATION end +|} |--- REPORT LOCATION OBSERVATION end +|=== + +====== 3.16.4.1.4 Trigger Events + +The HL7 trigger event is ORU^R45^ORU_R45. + +Any nomenclature used by the MEMLS Profile not yet in the IEEE 11073-10101 standard will be submitted for inclusion in the first available update to the standard. In the interim, MDC will be identified as MDCX, codes values will be zero, and interim REFID strings will be utilized. Once the standard has been updated to include the identifications, MEMLS actor implementations shall utilize the standardized MDC/REFID values. + +More sophisticated location services events can be derived from the above defined events using the observation attributes associated with the event message. For example a Mother-Baby mismatch, equipment collocation implying a patient to equipment binding, or arrival of a clinician to a room location which results in a change to a nurse call dome light. It is not within the scope of this profile to define the algorithms by which such sophisticated events are determined to have occurred or the actions which would result from such an occurrence. + +Typical application purposes for deployment of LS solutions are achievable using the above set of triggers. Additional triggers typically aren’t required. The triggering event is the underlying event that is the foundation for the application purposes. The table below offers some suggestions. + +Table 3.16.4.1.4-1: Application Purposes Mapped to Available Triggers + +[width="100%",cols="9%,51%,40%",options="header",] +|=== +|# |Application Purpose |Based Upon Available Triggers +|1 |Mother-Baby mismatch detection |Colocation +|2 |Infant abduction |Boundary or Colocation +|3 |Patient – equipment binding |Colocation +|4 |Clinician entering room or being near patient affecting equipment |Boundary or Colocation +|5 |Privacy/security, authentications and violations |Colocation or Boundary +|6 |Positive Patient Identification/Device Association |Colocation +|7 |Specimen tracking |Location observation, Movement, Boundary +|8 |Staff tracking (other than clinical) |Location Observation +|9 |Staff needing assistance |Dwell, Interaction, Tamper +|10 |Refrigerator/freezer monitoring |Environment +|11 |Violation of controlled environment |Environment +|12 |Infection prevention and control |Colocation (of staff to wash station) +|13 |Human resources log in/out for payroll |Colocation, Boundary +|14 |Communication device asset management |Location observation, Boundary +|15 |Delivery arrivals (pharmacy, supplies) |Location observation, Boundary +|16 |Closed Loop Medication Administration |Location observation, Colocation +|17 |Code/Nurse Calls |Location observation, Colocation +|18 |Food services workflow |Location observation, Boundary, Colocation +|19 |Automated/guided vehicle arrival/departure |Colocation +|20 |Supplies tracking |Location observation, Colocation +|21 |Transfer center workflow |Location observation, Colocation, Boundary +|=== + +====== 3.16.4.1.5 Message Semantics + +The message is an HL7 observation. The content of the message is governed by HL7, IHE DEV Technical Framework and this profile. The objects for which the observations are being reported are governed by IHEE 11073. + +The MDS, VMD, CHAN, and METRICs are to be reported per the IHE PCD Technical Framework. + +The HL7 version 2.7 Participation Information (PRT) segment is required as a child of the location type identifying OBX segment to identify the person in person associated location observations. For backwards compatibility if the location observation is equipment associated then the PRT segment need not be used and OBX segment field Equipment Instance Identifier OBX-18 can be used to identify the unique instance of the equipment. As of HL7 version 2.7 use of Equipment Instance Identifier OBX-18 is retained for backward compatibility and equipment identification has been moved to the PRT segment. Therefore use of the PRT segment for equipment location observations is considered forward looking. This applies to both MEMLS use cases (LS observations in other profiles, such as DEC, ACM, and IPEC and LS observations in the MEMLS Profile). + +Indicating Observation Result Status (OBX-11) as a value of R (Results entered – not verified) establishes an expectation that someone will manually verify the value of the observation. Review and verification of MEMLS Profile specific observations is not expected as they change over time and requiring someone to review and certify them is a workload with little return for the effort. Therefore MEMLS observations shall indicate a value of F (Final) in Observation Result Status (OBX-11). + +======= 3.16.4.1.5.1 Proposed additions to IEEE 11073-10101 + +Nomenclature items used in the MEMLS Profile which are not yet in the IEEE 11073-10101 standard will be submitted for inclusion in the first available update to the standard. In the interim MDC will be identified as MDCX, codes values will be zero, and interim REFID strings will be utilized. Identification of some observation identifications (MDC & REFID) are not be currently defined in Rosetta Terminology Mapping (RTM) or in IEEE 11073-10101 Nomenclature and so a submission will be required. After values are assigned they are likely to appear in the Rosetta Terminology Mapping Management System (RTMMS) prior to being balloted for an update to the standard. Once the standard has been updated to include the identifications MEMLS actor implementations shall utilize the standardized MDC/REFID values. + +Communication of the location of a person or piece of equipment by structured location as in, building, floor, point of care, room, bed, etc. is communicated using a separate instance of an OBX segment with OBX-3 Observation Identifier containing 68513^MDC_ATTR_LS_LOCATION^MDC and OBX-5 Observation Value containing the observed location in the format defined by the HL7 Person Location (PL) Data Type (see HL7 version 2.6 Chapter 2A Section 2.A.53 PL - Person Location) and indicating PL in OBX-2 Value Type. + +For backward compatibility with existing applications that only look for and process a single device single location observation per MEM LS Report Location Observation (RLO) [PCD-16] transaction, if multiple location observations for the same device are communicated in a single Report Location Observation (RLO) [PCD-16] transaction the first observation shall be the most fully resolved, meaning having the most non-empty components of the Person Location (PL) datatype, with lesser resolved location observations following it in order of decreasing completeness of resolution. See the note within the PL datatype definition in HL7 version 2.6 chapter 2A Control (DataTypes) page 53 which spells out PL component ordering. + +The Point of Care component of the Person Location (PL) datatype is meant to refer to the architecturally or business unit defined within the floor of a building, as in Recovery, Emergency, Radiology, etc. It is not meant to refer to a site on the body of a patient where care is administered. For patient body site indications, see HL7 2.6 Chapter 7 Observation Reporting section 7.4.2 Observation/Result Segment (OBX) Observation Site field (OBX-20). + +To indicate building structural compass ordinal wings in a location observation when using the Person Location (PL) datatype a common practice is to suffix the Point of Care (sequence 1) component with the compass ordinal indication, either abbreviated to reduce the length of the name string, i.e., ICU-W for ICU West or the full ordinal name. Continued use of site currently deployed structural identification strings, as used by the patient Admit/Discharge/Transfer (ADT) system, are likely to take precedence over changes to the strings. See the IHE Information Technology (ITI) domain profiles. + +Common areas, such as waiting rooms or hallways, are also likely to need encoding into the Person Location (PL) datatype. A common practice is to establish a reusable point of care unique Room component string value, such as Waiting, as used in ER^Waiting or OR^Waiting or ICU-W^Hall. + +Shared areas between two defined Room values, as in a bathroom shared by multiple rooms, are typically arbitrarily indicated by the healthcare institution as being associated with one of the Room name strings so as to more concisely direct a responding individual to the shared area. + +As it is defined in the HL7 standard an uncoded string the Location Description component (seq 9) of the Person Location (PL) datatype shall be avoided for communicating a hierarchical named location. It shall be reserved for optional additional information for improved human recognition, as in OR^Waiting^^^^^^^blue walls. + +HL7 Component Table – PL – Person Location + +[width="100%",cols="13%,9%,10%,10%,11%,32%,15%",options="header",] +|=== +|SEQ |LEN |DT |OPT |TBL# |COMPONENT NAME |SEC. REF. +|1 |20 |IS |O |0302 |Point of Care |2.A.36 +|2 |20 |IS |O |0303 |Room |2.A.36 +|3 |20 |IS |O |0304 |Bed |2.A.36 +|4 |227 |HD |O | |Facility |2.A.33 +|5 |20 |IS |O |0306 |Location Status |2.A.36 +|6 |20 |IS |C |0305 |Person Location Type |2.A.36 +|7 |20 |IS |O |0307 |Building |2.A.36 +|8 |20 |IS |O |0308 |Floor |2.A.36 +|9 |199 |ST |O | |Location Description |2.A.74 +|10 |427 |EI |O | |Comprehensive Location Identifier |2.A.25 +|11 |227 |HD |O | |Assigning Authority for Location |2.A.33 +|=== + +For definitive works always refer back to the originating version of the standard to make sure you’re using up to date information. + +Communication of equipment name shall be in a separate OBX segment occurrence with an observation containment identifying MDC/REFID in OBX-3 68512^MDC_ATTR_LS_NAME^MDC shall be used with the equipment name as the observation value in OBX-5 Observation Value. + +====== 3.16.4.1.6 Expected Actions + +In response to the receipt of the message the receiver will generate an HL7 acknowledgement to advise the sending of the status of the receipt of the message that was sent. + +As a result of receiving the observation the receiver can store the information for later retrieval or the information can be used to trigger the production of transactions in other IHE profiles, such the generation of an ACM alert. + +For backward compatibility with existing applications that only look for and process a single device single location observation per MEM LS Report Location Observation (RLO) [PCD-16] transaction, if multiple location observations for the same device are communicated in a single Report Location Observation (RLO) [PCD-16] transaction the first observation shall be the most fully resolved, meaning having the most non-empty components of the Person Location (PL) datatype, with lesser resolved location observations following it in order of decreasing completeness of resolution. See the note within the PL datatype definition in HL7 version 2.6 chapter 2A Control (DataTypes) page 53 which spells out PL component ordering. + +==== 3.16.5 Security Considerations + +During the Profile development there were no unusual security or privacy concerns identified. There are no mandatory security controls but the implementer is encouraged to use the underlying security and privacy profiles from ITI that are appropriate to the transports such as the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk assessment, following ISO 80001, will determine the actual security and safety controls employed. + +== Volume 2 Namespace Additions + +Add the following terms to the IHE General Introduction Appendix G: + +The following OIDs have been allocated to the MEMLS Profile. + +Specific IHE-PCD Transactions: 1.3.6.1.4.1.19376.1.6.16.9 / 1.3.6.1.4.1.19376.1.6.1.16.1 [PCD-16]. + +The 1.3.6.1.4.1.19376.1.6.1.16.1 will appear in MSH-21 to identify the [PCD-16] transaction. + +Specific IHE-PCD Conformance Profiles: 1.3.6.1.4.1.19376.1.6.6.16.1 [PCD-16] + +[#_Toc177639786 .anchor]####Appendices to Volume 2 + +== Appendix A – Transaction Examples + +These are the transaction examples for this profile. + +=== A.1 Report Location Observation for equipment + +The Report Location Observation (RLO) for equipment is the report of an observation of the location of a piece of equipment and the reason for the report. + +MSH|^~\&|Argus RFID System^00095F56787^EUI-64|Guard RFID Solutions|HEMS|EQ2|20140213165004.434-0800||ORU^R45^ORU_R45|132449|P|2.6||||||||| IHE_PCD_MEMLS_001^IHE PCD^1.3.6.1.4.1.19376.1.6.1.16.1^ISO + +OBR|1|||203776^MDC_EVT_LS_ DEVICE ^MDC|||20140213165004.434-0800 + +OBX|1|PL|68513^MDC_ATTR_LS_LOCATION ^MDC||^^^Fraser Health^^^South BuildingS^Floor 1^Emergency Department||||||F|||20140215181304.697-0500||||10006^THNAME^^~112212000001^TAGNO^^ + +OBX|2|ST|68512^MDC_ATTR_LS_NAME^MDC|LOC|IV Pump 2012078||||||F|||20150127110822.229-0800 + +OBX|3|NM|68525^MDC_ATTR_LS_COORD_X^MDC ||5350|263441^MDC_DIM_CENTI_M^MDC|||F|||20140215181304.697-0500||||10006^THNAME^^~112212000001^TAGNO + +OBX|4|NM|68526^MDC_ATTR_LS_COORD_Y^MDC ||16430|263441^MDC_DIM_CENTI_M^MDC|||F|||20140215181304.697-0500||||10006^THNAME^^~112212000001^TAGNO + +OBX|5|NM|68527^MDC_ATTR_LS_COORD_Z^MDC ||0|263441^MDC_DIM_CENTI_M^MDC|||F|||20140215181304.697-0500||||10006^THNAME^^~112212000001^TAGNO + +OBX|6|ST|68517^MDC_ATTR_LS_ REF_NAME^MDC|Fraser ED||||||F + +OBX|7|NM|68519^MDC_ATTR_LS_REF_GPS_LAT^MDC|26.0795|262880^MDC_DIM_ANG_DEG|||||F + +OBX|8|NM|68520^MDC_ATTR_LS_REF_LON^MDC|80.2287|262880^MDC_DIM_ANG_DEG |||||F + +OBX|9|NM|68521^MDC_ATTR_LS_REF_ALT^MDC||263424^MDC_DIM_X_M |||||F + +OBX|10|NM|68535^MDC_ATTR_GPS_COORD_ACCY^MDC||262880^MDC_DIM_ANG_DEG |||||F + +OBX|11|NM|68539^MDC_ATTR_GPS_ALT_ACCY^MDC||263424^MDC_DIM_X_M |||||F + +OBX|12|NM|68540^MDC_ATTR_GPS_HEADING^MDC|NaN|262880^MDC_DIM_ANG_DEG |||||F + +OBX|13|NM|68541^MDC_ATTR_GPS_SPEED^MDC|0|264960^MDC_DIM_X_M_PER_SEC|||||F + +The base referenced latitude and longitude can be agreed between systems in advance in which case the full lat/lon information is optional in the individual location observations so as to reduce the volume of data communicated over time. + +If lat/lon are passed and the additional attributes are not known they are also optional, particularly if the lat/lon is of a stationary location, such as a reference point for X/Y/Z coordinates in an LS system. + +The X/Y/Z coordinates are a new data type and so some definition is in order. + +X starts at zero at the left and progresses to the right + +Y starts at the bottom and progresses upwards + +Z starts at the bottom and progresses upwards + +The units of measure are specified in the observed value. + +If the Z coordinate is not supported it is optional and need not be sent with each observation. + +The base point reference name 68517^MDC_ATTR_LS_REF_NAME (“Fraser ED” in this example) defines an agreement between systems that is external to the communication of individual location observations. This agreement would also likely include a graphical image file representing the structural area of the building and the format of the file. It would be wasteful of communication bandwidth and processing power to communicate this on every location observation. + +While this message contains many OBX segments relating to X, Y, Z, and baseline offsets as well as GPS coordinates most messages making use of an OBX using the PL data type to indicate a named location is sufficient and the additional OBX segments are optional. + +=== A.2 Report Location Observation for people + +The Report Location Observation (RLO) for equipment is the report of an observation of the location of a person and the reason for the report. This would be similar to the previous example except that it would additionally include a Participation Information (PRT) segment beneath the OBX segment as the means of communication of the person location. As this observation transaction is associated with Use Case #2 of this profile there would be no patient specific information in the PID and PV1 segments. + +MSH|^~\&|Argus RFID System^00095F56787^EUI-64|Guard RFID Solutions|HEMS|EQ2|20140213165004.434-0800||ORU^R45^ORU_R45|132449|P|2.6||||||||| IHE_PCD_MEMLS_001^IHE PCD^1.3.6.1.4.1.19376.1.6.1.16.1^ISO + +OBR|1|||203778^MDC_EVT_LS_ PERSON ^MDC|||20140213165004.434-0800 + +OBX|1|PL|68513^MDC_ATTR_LS_LOCATION ^MDC||^^^Fraser Health^^^South BuildingS^Floor 1^Emergency Department ||||||F|||20140215181304.697-0500||||10006^THNAME^^~112212000001^TAGNO^^ + +PRT|1|AD||RO|^Smith^John|Patient|1|Fraser_Health|^^^Fraser_Health^^^North_Building^Floor_1^LnD|^^112204006564^GuardRFID|20160204143332.4658-0800 + +The value in PRT-2 Action Code is AD indicating ADD. The value in PRT-4 Participation is RO indicating Responsible Observer. + +[#_Toc177639790 .anchor]####Volume 3 – Content Modules + +None + +== 5 Namespaces and Vocabularies + +Add to Section 5 Namespaces and Vocabularies + +None + +== 6 Content Modules + +Not applicable. CDA is not being produced. + +== Volume 3 Namespace Additions + +Add the following terms to the IHE Namespace: + +None + +[#_Toc177639794 .anchor]####Volume 4 – National Extensions + +Add appropriate Country section + +== 4 National Extensions + +None at this time diff --git a/CP Work/Balloted Not Incorporated/CP-PCD-160-MWP_MEM_LS_Multiple_Location_Observations,_PL_Clarity_02.docx b/Supplement Repos/memls/CP/Ballotted Not Incorporated/CP-PCD-160-MWP_MEM_LS_Multiple_Location_Observations,_PL_Clarity_02.docx similarity index 100% rename from CP Work/Balloted Not Incorporated/CP-PCD-160-MWP_MEM_LS_Multiple_Location_Observations,_PL_Clarity_02.docx rename to Supplement Repos/memls/CP/Ballotted Not Incorporated/CP-PCD-160-MWP_MEM_LS_Multiple_Location_Observations,_PL_Clarity_02.docx diff --git a/Supplement Repos/memls/archived docx/IHE_DEV_Suppl_MEMLS_Rev1-5_TI_2024-09-19.docx b/Supplement Repos/memls/archived docx/IHE_DEV_Suppl_MEMLS_Rev1-5_TI_2024-09-19.docx new file mode 100644 index 0000000..80b7ddb Binary files /dev/null and b/Supplement Repos/memls/archived docx/IHE_DEV_Suppl_MEMLS_Rev1-5_TI_2024-09-19.docx differ diff --git a/TF Final Text Versions/README.md b/TF Final Text Versions/README.md deleted file mode 100644 index e905f4f..0000000 --- a/TF Final Text Versions/README.md +++ /dev/null @@ -1,4 +0,0 @@ -# DEV / TF Final Text Versions -IHE Devices Domain (DEV) technical framework (TF) document volumes that have been published to date on the [IHE Technical Frameworks web page](https://www.ihe.net/resources/technical_frameworks/#dev). This includes both the Word .docx files, any related files (e.g., separate graphics that are included, or PlantUML source files) and their PDF rendering. - -Note: This is modeled on the original IHE FTP site; it may be modified in the future as the TF development / maintenance process evolves. diff --git a/TF Final Text Versions/Rev_9.0 2019/IHE_PCD_TF_Vol1 2019-12-12.pdf b/TF Final Text Versions/Rev_9.0 2019/IHE_PCD_TF_Vol1 2019-12-12.pdf deleted file mode 100644 index 6ff8ae0..0000000 Binary files a/TF Final Text Versions/Rev_9.0 2019/IHE_PCD_TF_Vol1 2019-12-12.pdf and /dev/null differ diff --git a/TF Final Text Versions/Rev_9.0 2019/IHE_PCD_TF_Vol2 2019-12-12.pdf b/TF Final Text Versions/Rev_9.0 2019/IHE_PCD_TF_Vol2 2019-12-12.pdf deleted file mode 100644 index 2c99fbc..0000000 Binary files a/TF Final Text Versions/Rev_9.0 2019/IHE_PCD_TF_Vol2 2019-12-12.pdf and /dev/null differ diff --git a/TF Final Text Versions/Rev_9.0 2019/IHE_PCD_TF_Vol3 2019-12-12.pdf b/TF Final Text Versions/Rev_9.0 2019/IHE_PCD_TF_Vol3 2019-12-12.pdf deleted file mode 100644 index 4debe39..0000000 Binary files a/TF Final Text Versions/Rev_9.0 2019/IHE_PCD_TF_Vol3 2019-12-12.pdf and /dev/null differ diff --git a/TF Supplements/Profile Proposals/IHE_Suppl_DEV_Profile_Monitored_Communication.docx b/TF Supplement Proposals/IHE_Suppl_DEV_Profile_Monitored_Communication.docx similarity index 100% rename from TF Supplements/Profile Proposals/IHE_Suppl_DEV_Profile_Monitored_Communication.docx rename to TF Supplement Proposals/IHE_Suppl_DEV_Profile_Monitored_Communication.docx diff --git a/TF Supplements/README.md b/TF Supplements/README.md deleted file mode 100644 index 8aab3bd..0000000 --- a/TF Supplements/README.md +++ /dev/null @@ -1,8 +0,0 @@ -# DEV / TF Supplements -IHE Devices Domain (DEV) technical framework (TF) supplement work products that are either in development, in Public Comment or Trial Implementation and may be published on the [IHE Technical Frameworks web page](https://www.ihe.net/resources/technical_frameworks/#dev). This includes both the Word .docx files, any related files (e.g., separate graphics that are included, or PlantUML source files) and their PDF rendering. - -NOTEs: -1. Supplement revisions should also be supported until the trial implementation (TI) versions have been converted to final text (FT) and integrated into the IHE DEV TF. -2. Supplement-specific GitHub repositories contain the pre-public development artifacts for each supplement. They get moved here to the DEV domain when versions are circulated for comment and publication. - -Note: Though this was originally modeled after the IHE FTP site, the folder structure for each supplement may evolve as the development processes evolve. diff --git a/Technical Frameworks/AsciiDoc Source/common/placeholder.adoc b/Technical Frameworks/AsciiDoc Source/common/placeholder.adoc new file mode 100644 index 0000000..e69de29 diff --git a/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image1.jpeg b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image1.jpeg new file mode 100644 index 0000000..4459cc0 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image1.jpeg differ diff --git a/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image10.png b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image10.png new file mode 100644 index 0000000..03bf75c Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image10.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image2.emf b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image2.emf new file mode 100644 index 0000000..e10c80c Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image2.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image4.png b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image4.png new file mode 100644 index 0000000..1422c8e Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image4.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image5.png b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image5.png new file mode 100644 index 0000000..01d940e Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image5.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image6.emf b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image6.emf new file mode 100644 index 0000000..45c153e Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image6.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image7.emf b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image7.emf new file mode 100644 index 0000000..919a938 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image7.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image8.png b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image8.png new file mode 100644 index 0000000..29c02da Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf1/extracted-media-tf1/media/image8.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf1/tf1.adoc b/Technical Frameworks/AsciiDoc Source/tf1/tf1.adoc new file mode 100644 index 0000000..0296b67 --- /dev/null +++ b/Technical Frameworks/AsciiDoc Source/tf1/tf1.adoc @@ -0,0 +1,1012 @@ += TF3 +:toc: left +:showtitle!: + +*Integrating the Healthcare Enterprise* + +image:extracted-media-tf1/media/image1.jpeg[IHE_LOGO_for_tf-docs,width=171,height=88] + +*IHE Devices (DEV)* + +*Technical Framework* + +*Volume 1* + +*IHE PCD TF-1* + +*Profiles* + +*Revision 10.0 – Final Text* + +*November 4, 2024* + +*Please verify you have the most recent version of this document,* which is published https://profiles.ihe.net/DEV/index.html[here]. + +== Introduction + +This document, Volume 1 of the IHE Devices (DEV) Technical Framework, describes the clinical use cases, actors, content module, and transaction requirements for the Devices profiles. + +=== Introduction to IHE + +Integrating the Healthcare Enterprise (IHE) is an international initiative to promote the use of standards to achieve interoperability among health information technology (HIT) systems and effective use of electronic health records (EHRs). IHE provides a forum for care providers, HIT experts and other stakeholders in several clinical and operational domains to reach consensus on standards-based solutions to critical interoperability issues. + +The primary output of IHE is system implementation guides, called IHE profiles. IHE publishes each profile through a well-defined process of public review and Trial Implementation and gathers profiles that have reached Final Text status into an IHE Technical Framework, of which this volume is a part. + +For general information regarding IHE, refer to http://www.ihe.net[www.ihe.net]. + +=== Introduction to IHE Devices (DEV) + +The Devices (DEV) domain is concerned with use cases in which at least one actor is a regulated patient-centric point-of-care medical device that communicates with at least one other actor such as a medical device or information system. + +The DEV domain coordinates with and supports other domains, such as Radiology (medical imaging), IT Infrastructure and Pathology and Laboratory Medicine to ensure consistency in use cases involving regulated medical devices as they occur throughout the Enterprise. + +*DEV Vision Statement* + +The DEV domain is the nexus for vendors and providers to jointly define and demonstrate unambiguous interoperability specifications, called profiles, which are based on industry standards, and which can be brought to market. + +*DEV Mission Statement* + +The DEV domain, working with regional and national deployment committees, will apply the proven, use case driven IHE processes to: + +* Deliver the technical framework for the IHE DEV domain profiles +* Test conformance with published IHE DEV profiles using test plans, tools and scripts at Connectathons +* Demonstrate marketable solutions at public trade shows + +The DEV domain manages the development and maintenance of the http://wiki.ihe.net/index.php?title=PCD_Profiles[DEV Profiles] and the https://wiki.ihe.net/index.php/DEV_Technical_Framework[DEV Technical Framework]. + +=== Intended Audience + +The intended audience of IHE Technical Frameworks Volume 1 (Profiles) is: + +* Those interested in integrating healthcare information systems and workflows +* IT departments of healthcare institutions +* Technical staff of vendors participating in the IHE initiative + +=== Pre-requisites and Reference Material + +It is strongly recommended that, prior to reading this volume, readers familiarize themselves with the concepts defined in the https://profiles.ihe.net/GeneralIntro/[IHE Technical Frameworks General Introduction]. + +Additional reference material available includes: + +==== Actors + +Actors are information systems or components of information systems that produce, manage, or act on information associated with operational activities in the enterprise. + +For information on actors for all domains and their brief descriptions, see IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-A.html[Appendix A] - Actors. + +==== Transactions + +Transactions are interactions between actors that transfer the required information through standards-based messages. + +For information on transactions defined for all domains, their transactions numbers, and a brief description, see IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-B.html[Appendix B - Transactions]. + +==== IHE Integration Statements + +IHE Integration Statements provide a consistent way to document high level IHE implementation status in products between vendors and users. + +The instructions and template for IHE Integration Statements can be found in the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-F.html[Appendix F] - Integration Statements. + +IHE also provides the IHE Product Registry (http://www.ihe.net/IHE_Product_Registry/[http://www.ihe.net/IHE_Product_Registry]) as a resource for vendors and purchasers of HIT systems to communicate about the IHE compliance of such systems. Vendors can use the Product Registry to generate and register Integration Statements. + +=== Overview of Technical Framework Volume 1 + +Volume 1 is comprised of several distinct sections: + +* Section 1 provides background and reference material. +* Section 2 presents the conventions used in this volume to define the profiles and provides an overview of the defined profiles. +* Sections 3 and beyond define Devices profiles, actors, and requirements in detail. + +The appendices in Volume 1 provide clarification of uses cases or other details. + +For a brief overview of additional Technical Framework Volumes (TF-2, TF-3, TF-4), please see the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-5.html[Section 5]. + +=== Comment Process + +IHE International welcomes comments on this document and the IHE initiative. Comments on the IHE initiative can be submitted by sending an email to the co-chairs and secretary of the Devices domain committees at devdev@ihe.net. Comments on this document can be submitted at https://www.ihe.net/DEV_Public_Comments/[https://www.ihe.net/DEV_Public_Comments]. + +=== Copyright Licenses + +IHE technical documents refer to, and make use of, a number of standards developed and published by several standards development organizations. Please refer to the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-9.html[Section 9 - Copyright Licenses] for copyright license information for frequently referenced base standards. Information pertaining to the use of IHE International copyrighted materials is also available there. + +=== Trademark + +IHE^®^ and the IHE logo are trademarks of the Healthcare Information Management Systems Society in the United States and trademarks of IHE Europe in the European Community. Please refer to the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-10.html[Section 10 - Trademark] for information on their uses. + +=== Disclaimer Regarding Patent Rights + +Attention is called to the possibility that implementation of the specifications in this document may require use of subject matter covered by patent rights. By publication of this document, no position is taken with respect to the existence or validity of any patent rights in connection therewith. IHE International is not responsible for identifying Necessary Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of the specifications in this document are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information about the IHE International patent disclosure process including links to forms for making disclosures is available at http://www.ihe.net/Patent_Disclosure_Process/[http://www.ihe.net/Patent_Disclosure_Process]. Please address questions about the patent disclosure process to the secretary of the IHE International Board: secretary@ihe.net. + +=== History of Document Changes + +This section provides a brief summary of changes and additions to this document. + +[width="100%",cols="14%,14%,72%",options="header",] +|=== +|Date |Document Revision |Change Summary +|2014-11-04 |4.0 |Added Alert Consumer to Alert Communication Management Profile. Rearranged material to conform to current template for Technical Framework Volume 1. +|2015-10-14 |5.0 |Updated ACM Profile with approved CPs and housekeeping corrections. +|2016-11-09 |6.0 |Added cross-reference to ITI mACM Profile +|2017-11-09 |7.0 |Updated ACM Profile for CP 132 ACM Use Case A6 to indicate that the Alert Consumer (ACon) is an additional recipient and that the decision to log only is implementation specific. +|2018-10-23 |8.0 |Updated some wording in Section 1 and links to the General Introduction and associated appendices. +|2019-12-12 |9.0 a| +Infusion Pump Event Communication (IPEC) has been accepted by IHE DEV Technical and Planning Committees for Final Text status; therefore, Section 7 Infusion Pump Event Communication (IPEC) has been added to this Technical Framework document. + +Volume 1 changes in accepted Change Proposals 139-146 have been applied, specifically PIV extensions for bolus and multistep in CP 139. Other CPs did not affect Volume 1 material. + +|NOV 2024 |10.0 |Updates due to Patient Care Device name change to Devices and to reflect current template. +|=== + +== Devices Integration Profiles + +IHE Integration Profiles offer a common language that healthcare professionals and vendors can use to discuss integration needs of healthcare enterprises and the integration capabilities of information systems in precise terms. Integration Profiles specify implementations of standards that are designed to meet identified clinical needs. They enable users and vendors to state which IHE capabilities they require or provide, by reference to the detailed specifications of the IHE Devices Technical Framework. + +IHE Integration Profiles are defined in terms of IHE actors (defined in Volume 1), transactions (defined in Volume 2), and content modules (defined in Volume 3). Actors are information systems or components of information systems that produce, manage, or act on information associated with clinical and operational activities in healthcare. Transactions are interactions between actors that communicate the required information through standards-based messages. Content modules define how the content used in a transaction is structured. A content module is specified to be independent of the transaction in which it appears. + +Vendor products support an Integration Profile by implementing the appropriate actor(s) and transactions. A given product may implement more than one actor and more than one integration profile. + +IHE profiles which have reached the status of _Final Text_ are published as part of the domain’s Technical Framework Volumes 1-4. Prior to Final Text status, IHE profiles are published independently as _Profile Supplements_ with the status of _Public Comment_ or _Trial Implementation_. + +For a list and short description of Devices profiles, see https://wiki.ihe.net/index.php/Profiles%23IHE_Devices_Profiles[https://wiki.ihe.net/index.php/Profiles#IHE_Devices_Profiles]. The list includes all of the profiles in this document (Final Text) and may include profiles in the Trial Implementation and Public Comment stage. + +=== Required Actor Groupings and Bindings + +The IHE Technical Framework relies on the concepts of _required actor groupings_ and _bindings_. + +Required actor groupings may be defined between two or more IHE actors. Actors are grouped to combine the features of existing actors. This allows reuse of features of an existing actor and does not recreate those same features in another actor. Internal communication between grouped actors is not specified by IHE. An example of grouped actors in the IHE Radiology Scheduled Workflow Profile is the grouping between the Image Manager and Image Archive. + +Additionally, required actor groupings may cross profile boundaries. For example, an XDS Document Registry is required to be grouped with an ATNA Secure Node. Required actor groupings are defined in each profile definition in Volume 1. To comply with an actor in an IHE profile, a system must perform all transactions required for that actor in that profile. Actors supporting multiple Integration Profiles must support all of the transactions of each profile. (Note: In previous versions of IHE Technical Framework documents, the concept of profile dependencies existed. For simplification, profile dependencies have been combined with required actor groupings and are enumerated/repeated within each profile in Volume 1.) + +Bindings refer to content modules. Bindings map data from a content module to the metadata of a specific transport profile. Bindings for content modules, and the associated concepts, are defined in Volume 3. + +=== Security Implications + +IHE transactions often contain information that must be protected in conformance with privacy laws, regulations and best practices. This protection is documented in the Security Considerations section of each profile, which communicates security/privacy concerns that the implementers need to be aware of, assumptions made about security/privacy pre-conditions and, where appropriate, key elements of a risk mitigation strategy to be applied. + +=== Profiles Overview + +A brief overview of Devices profiles is provided on the IHE Wiki at https://wiki.ihe.net/index.php/Profiles%23IHE_Devices_Profiles[https://wiki.ihe.net/index.php/Profiles#IHE_Devices_Profiles]. The list includes all of the profiles in this document (Final Text) and may include profiles in the Trial Implementation and Public Comment stage. + +=== Product Implementations + +As described in detail in the https://profiles.ihe.net/GeneralIntro/index.html[IHE Technical Frameworks General Introduction], an implementer chooses specific profiles, actors, and options to implement for their product. To comply with an actor in an IHE profile, a system must perform all the required transactions for that actor in that profile. + +To communicate the conformance of a product offering with IHE profiles, implementers provide an IHE Integration Statement describing which IHE integration profiles, IHE actors and options are incorporated. + +Further discussion about integration statements and a sample form can be found in the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-F.html[Appendix F]. To make consumers aware of the product integration statement, enter it in the IHE Product Registry (http://product-registry.ihe.net/). + +=== Dependencies between Integration Profiles + +Dependencies among IHE Integration Profiles exist when implementation of one integration profile is a prerequisite for achieving the functionality defined in another integration profile. Table 2.5-1 defines the required dependencies. Some dependencies require that an actor supporting one profile be grouped with one or more actors supporting other integration profiles. + +There are of course other useful synergies that occur when different combinations of profiles are implemented, but those are not described in the table below. For instance, actors of the various DEV profiles may implement profiles of the IT Infrastructure domain for user or node authentication, audit trails, patient identifier cross-referencing, etc. + +Table 2.5-1: Devices Integration Profile Dependencies + +[width="100%",cols="25%,32%,23%,20%",options="header",] +|=== +|Integration Profile |Depends on |Dependency Type |Purpose +|Device Enterprise Communication (DEC) |Consistent Time |Each actor implementing DEC shall be grouped with the Time Client |Required for consistent time-stamping of messages and data +|Point-of-Care Infusion Verification (PIV) |Consistent Time |Each actor implementing PIV shall be grouped with the Time Client |Required for consistent time-stamping of messages and data +|Alert Communication Management (ACM) |Consistent Time |Each actor implementing ACM shall be grouped with the Time Client |Required for consistent time-stamping of messages and data +|Implantable Device - Cardiac – Observation (IDCO) |None |N/A |N/A +|Infusion Pump Event Communication (IPEC) |Consistent Time |Each actor implementing IPEC shall be grouped with the Time Client |Required for consistent time-stamping of messages and data +|=== + +Vendor products support an Integration Profile by implementing the appropriate actor-transactions as outlined in the Integration Profile in Section 3. A product may implement more than one actor and more than one Integration Profile. + +To support a dependent profile, an actor must implement all required transactions in the pre-requisite profiles in addition to those in the dependent profile. In some cases, the prerequisite is that the actor selects any one of a given set of profiles. + +Actors are information systems or components of information systems that produce, manage, or act on information associated with operational activities in the enterprise. + +Transactions are interactions between actors that transfer the required information through standards-based messages. + +=== Rosetta Terminology Mapping (RTM) + +The Rosetta Terminology Mapping has general application in IHE DEV Profiles. + +The primary purpose of the Rosetta Terminology Mapping (RTM) managed value set is to _harmonize the use of existing ISO/IEEE 11073-10101 nomenclature terms_ by systems compliant with IHE DEV profiles. The RTM Profile also specifies the _units-of-measure_ and _enumerated values_ permitted for each numeric parameter to facilitate safe and interoperable communication between devices and systems. Use of RTM is required in IHE-DEV profiles. + +The Rosetta Table also is designed to serve as a temporary repository that can be used to define _new nomenclature terms_ that are currently not present in the ISO/IEEE 11073-10101 nomenclature. Based on our experience to date, well over 100 new terms will be required, principally in the area of ventilator and ventilator settings. The RTM will also serve as a framework for capturing new terms to support the IEEE 11073 ‘Personal Health Devices’ (PHD) initiative. Additional information on RTM can be found in Appendix A. + +== Device Enterprise Communication (DEC) Profile + +The Device Enterprise Communication Integration Profile supports communication of vendor independent, multi-modality Patient Care Devices data to Enterprise Applications using consistent semantics. It accomplishes this by mapping PCD data from proprietary syntax and semantics into a single syntactic and semantic representation for communication to the enterprise. The PCD data is time stamped with a consistent enterprise time. Options are provided to allow applications to filter particular PCD data of interest. + +=== DEC Actors and Transactions + +The following figure diagrams the actors involved with this profile and the transactions between actors. + +Figure 3.1-1: DEC Integration Profile with Actors and Transactions + +Table 3.1-1: DEC - Actors and Transactions lists the transactions for each actor directly involved in the DEC Integration Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options defined by this Integration Profile that implementations may choose to support is listed in Section 3.2. + +Table 3.1-1: DEC - Actors and Transactions + +[width="100%",cols="22%,44%,16%,18%",options="header",] +|=== +|Actors |Transactions |Optionality |Section in Volume 2 +|Device Observation Consumer |Communicate PCD Data [PCD-01] |R |Section 3.1 +|Device Observation Reporter |Communicate PCD Data [PCD-01] |R |Section 3.1 +|=== + +Refer to Table 2.5-1: Devices Integration Profile Dependencies for other profiles that may be pre-requisites for this profile. + +==== Patient Demographics – Recommended Transactions + +While not required, it is recommended that IHE transactions be employed for acquisition of Patient Demographics from other systems. The recommended transactions include: + +____ +*Patient Demographics Query* – This transaction contains the Patient Demographics information in response to a specific query on a specific patient. [ITI-21] + +*Patient Identity Feed* - This transaction is broadcast from the Patient Demographics supplier when changes to the patient demographics occur. [ITI-30] + +*Patient Encounter Management* - The Patient Encounter Source registers or updates an encounter (inpatient, outpatient, pre-admit, etc.) and forwards the information to other systems implementing the Patient Encounter Consumer. This information will include the patient’s location and care providers for a particular (usually current) encounter. [ITI-31] +____ + +=== DEC Profile Options + +Many actors have options defined in order to accommodate variations in use across domains or implementations. Options that may be selected for this integration profile are listed in Table 3.2-1: DEC - Actors and Options along with the actors to which they apply. A subset of these options is required for implementation by actors in this profile (although they may be truly optional in other profiles). + +Table 3.2-1: DEC - Actors and Options + +[width="100%",cols="38%,43%,19%",options="header",] +|=== +|Actor |Option Name |Section in Volume 2 +|Device Observation Reporter |_No option (assumes MLLP Transport)_ |Appendix I +| |_Web Services (WS*) Transport Option (rather than default MLLP Transport)_ |Appendix J +|Device Observation Consumer |_None (assumes MLLP Transport)_ |Appendix I +| |_Web Services (WS*) Transport Option (rather than default MLLP Transport)_ |Appendix J +|=== + +=== DEC Overview + +In a recent HIMSS survey of requirements for Devices (DEV), the respondents identified Enterprise Sharing of PCD data as their highest priority. Goals include shortening decision time, increasing productivity, minimizing transcription errors, and obtaining increased contextual information regarding the data. + +PCD data includes: + +* Periodic physiologic data (heart rate, invasive blood pressure, respiration rate, etc.) +* Aperiodic physiologic data (non-invasive blood pressure, patient weight, cardiac output, etc.) +* Alarm and alert information +* Device settings and the ability to manipulate those settings +* CLIA waived (or equivalent international waiver) point-of-care laboratory tests (i.e., home blood glucose, etc.) + +PCD data may also include contextual data such as the patient ID, caregiver identification, and physical location of the device. + +The Device Enterprise Communication (DEC) Profile addresses the need for consistent communication of PCD data to the enterprise. Enterprise recipients of PCD data include, but are not limited to, Clinical Decision Support applications, Clinical Data Repositories (CDRs), Electronic Medical Record applications (EMRs), and Electronic Health Records (EHRs). + +The current profile does not address issues of privacy, security, and confidentiality associated with cross-enterprise communication of PCD data. The assumption is made that the DEC Profile is implemented in a single enterprise on a secure network. These aspects are on the IHE DEV roadmap for subsequent years. + +The current profile does not address use cases and transactions associated with either open loop or closed loop control of patient care devices. Real-time data such as alarms and alerts, waveforms (ECG, EEG, etc.) is currently not addressed. + +==== Note on Patient Identification + +Patient Identification is perhaps the most essential infrastructural component of any interoperability and communication process, particularly when PCD data is exported to the enterprise. It is the key element in medical device, communication, data analysis, reporting and record keeping. Automation of the entry of patient identification to patient care device has the potential for improving throughput, reducing errors, increasing safety and device and drug effectiveness, and efficiency. It is strongly recommended that implementations use IHE compliant transactions for acquisition of Patient Identification credentials. These transactions include ITI-21, ITI-30 and ITI-31. Other mechanisms such as bar code or RFID are also perfectly valid alternatives or complements. + +=== DEC Use Cases + +This Section describes the specific use cases and interactions defined for the DEC Workflow Profile. There are both standard Use Cases as well as optional Use Cases. + +==== Standard Use Cases + +===== Case DEC-1: Communicate patient identified DEC data to EMR/EHR + +Data from all of the patient care devices associated with a particular patient is communicated by a Gateway, Device or Clinical Information System (CIS) implementing the Device Observation Reporter to an EMR/EHR, implementing the Device Observation Consumer. Examples include data from bedside monitors, ventilators, and infusion pumps. Discrete parameters representing both periodic and aperiodic data are typically communicated at an interval of no less than once per minute. The data is time stamped with a consistent time across the data from the respective patient care devices. + +The primary intent is communication of structured data; however, provisions are made for inclusion of unstructured data. The application provides facilities to bind an authoritative enterprise patient identifier required for inclusion of the PCD data in the patient record. The workflow for associating the authoritative enterprise patient identifier to the PCD data is outside the scope of the current DEV Technical Framework. + +===== Case DEC-2: Communicate validated periodic DEC data to EMR/EHR + +This Use Case builds on Case DEC-1 by communicating only data which has been validated by a caregiver by identifying the caregiver in the PCD data. The workflow implementing validation is outside the scope of the current DEV TF. + +image:extracted-media-tf1/media/image2.emf[extracted-media-tf1/media/image2] + +Figure 3.4.1.2-1: DEC Process Flow (No filtering) + +==== Optional Use Cases for Automatic Patient Demographics Acquisition + +The following examples describe which actors typical systems might be expected to support. This is not intended to define requirements, but rather to provide illustrative examples. + +* A general purpose observation reporting gateway which combines the Device Observation Reporter and patient demographics. +* A patient care device which bundles the Device Observation Reporter and patient demographics. +* Patient Demographic Data that can be used in identifying the patient includes the following: +* Partial or complete patient name (printed on the patient record or wrist band, or related by the patient) +* Patient ID (from printed barcode, bedside chart, RFID, scan, etc.) +* Date of Birth / age range + +Note: Bed ID is not accepted by the Joint Commission as a means of patient identity verification. + +Patient Identification Binding Use Cases: The caregiver connects the patient to a patient care device. The patient is physically identified by the caregiver, using some institutionally unique protocol for identification such as verification of information contained on a wristband. The caregiver uses the information from the physical patient identification to authorize an electronic identification, made by the device or an independent device or system, binding the patient’s electronic identity to all data communicated from the patient care device. The verification may involve direct entry of data to the device being bound, a gateway, or an actor residing in a separate system. It may be based on direct physical identification of the patient by the caregiver or on confirmation by the caregiver of an electronic identification made by the device in concert with other devices or systems. The verification may also include fully automated binding when a unique logical authentication can be made. The end result is that data communicated from the patient care device contains an authoritative institutionally unique electronic identifier. + +===== Case DEC-ID-1: Patient ID known in ADT, locally available + +Note: The following are Use Cases in support of automatic acquisition of patient demographics. They do not map into any specific DEV profiles or transactions. + +A patient is connected to a bedside monitor of a cardiac monitoring system (e.g., central station with continuous ADT feed via PAM broadcasts that includes a number of bedside monitors. The patient may or may not be able to provide positive ID information. Demographic information used to identify a patient includes: partial or complete patient name (printed on the patient record or told by the patient); Patient MRN (this may be obtained from printed barcode, a bedside chart, etc.); Partial ID entry or scan; Date of birth / age range. _Note: Bed ID is not permitted as an identifier in accord with Joint Commission standards.)_ Caregiver selects the patient from a pick list on the system console, in response to prompts by caregiver. System information includes showing the Medical Record Number (MRN), full name, age, sex, room/bed, and admit date. The central station binds the patient identity information with the device data. + +===== Case DEC-ID-2: Patient ID known in ADT, not locally available + +In the event that the patient above is not registered in the cardiac monitoring system, due to ADT lag or other situations, caregiver can execute a PDQ query of the patient registry to receive a pick list of patients and enter the patient ID into the system + +===== Case DEC-ID-3 Patient ID not known in ADT, locally available + +This is the John/Jane Doe patient, for whom the system has set up a Proxy Identification. The Proxy Identification is determined by either method, in accord with institutional policy and later linked with the true patient ID via ITI-PAM. + +===== Case DEC-ID-4: Patient ID not known in ADT, not locally available. + +This is the case of a patient presenting in the ER who is not registered in the system, where care must continue and identification may follow. When the patient demographics are unknown, time and device MAC address can be sent automatically, providing unique identification to the data. This last approach can also be used to create an audit trail as a complement to the other binding mechanisms. + +===== Other Clinical Examples + +*DEC-ID-A*: A patient is connected to an infusion device. The infusion device is connected to the network but is not managed by an infusion or drug administration management application. Caregiver scans barcode of the patient and the device. Caregiver is presented with a display of patient IDs from ADT and device ID from an authoritative database. Caregiver confirms. + +*DEC-ID-B*: A patient is connected to an infusion device. The infusion device is connected to the network but is not managed by an infusion or drug administration management application. No ADT feed is available to confirm the ID. Caregiver confirms patient’s wristband identity through interactive communication with patient. The Patient ID wristband is scanned (barcode, RFID, etc.) and bound to the PCD. + +*DEC-ID-C*: A patient is connected to a ventilator. The ventilator is connected to the network but is not managed by a system. Ventilator and patient have RFID tags. Proximity of the tags implies binding of patient’s ADT identification and device’s ID from an authoritative database. Verification of an existing Order for a Ventilator for the identified patient is required. If verified, Patient Id is bound to PCD. + +== Point-of-Care Infusion Verification (PIV) Profile + +The Point-of-Care Infusion Verification Profile supports the electronic transfer of infusion parameters from a Bedside Computer assisted Medication Administration (BCMA) system to an infusion pump, including general purpose, syringe, or patient-controlled analgesia (PCA) pumps. This capability will reduce errors by eliminating keystroke errors and by increasing the use of automatic dosage checking facilitated by the onboard drug libraries in “smart pump” systems. In addition to the reduction of medication administration errors, this integration may also increase caregiver productivity and provide more contextual information regarding infusion data. + +Electronic transfer of infusion information from a pump to a clinical information system once an infusion has started can be accomplished using the Communicate PCD Data [PCD-01], possibly with Subscribe to PCD Data [PCD-02] transactions of the IHE DEV Device Enterprise Communication (DEC) Profile, as well as Communicate Infusion Event Data [PCD-10] of the IHE DEV Infusion Pump Event Communication (IPEC) Profile. + +The goal of the proposed integration is to bring infusion systems into the electronic medication administration and documentation process. + +=== PIV Actors and Transactions + +Figure 4.1-1 shows the actors involved in the Point-of-Care Infusion Verification Integration Profile and the relevant transactions between them. + +Figure 4.1-1: Point-of-Care Infusion Verification Actor Diagram + +Table 4.1-1 lists the transactions for each actor directly involved in the Point-of-Care Infusion Verification Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” involve optional actors. A complete list of options defined by this Integration Profile and that implementations may choose to support is listed in Section 3.3. + +Table 4.1-1: Point-of-Care Infusion Verification Integration Profile - Actors and Transactions + +[width="100%",cols="31%,37%,16%,16%",] +|=== +|Actors |Transactions |Optionality |Section in Vol. 2 +|Infusion Order Programmer |Communicate Infusion Order [PCD-03] |R |3.3 +|Infusion Order Consumer |Communicate Infusion Order [PCD-03] |R |3.3 +|=== + +=== Integration Profile Options + +Options that may be selected for this Integration Profile are listed in the Table 4.2-1 along with the actors to which they apply. Dependencies between options when applicable are specified in notes. + +Table 4.2-1: Evidence Documents - Actors and Options + +[width="100%",cols="34%,27%,39%",] +|=== +|Actor |Options |Section in Volume 2 +|Infusion Order Programmer |_No options defined_ |- - +|Infusion Order Consumer |_No options defined_ |- - +|=== + +=== PIV Overview + +The goal of the proposed integration is to bring infusion systems into the electronic medication administration process. The following primary steps comprise this process: + +* Order medication +* Verify order +* Prepare and dispense medication +* Administer medication + +While medication errors can occur at each point in this process, this profile is concerned with the “Administer medication” step, where half of the errors made by clinicians involve infusions. + +These errors usually involve a breach of one of the 5 Rights of Medication Administration: + +* Right Patient +* Right Drug +* Right Dose +* Right Route +* Right Time + +It is the caregiver’s responsibility to ensure that these rights are reviewed prior to administering each drug or starting each infusion. + +Because manual programming of the pump may still result in administration errors, this profile was developed to support automated programming of the pump, thereby closing the loop between the clinician who uses a BCMA system to verify the 5 Rights and the actual programming of the pump. + +The Point-of-Care Infusion Verification Profile supports the electronic transfer of infusion parameters from a Bedside Computer assisted Medication Administration (BCMA) system to an infusion pump. This capability will reduce errors by eliminating keystroke errors and by increasing the use of automatic dosage checking facilitated by the onboard drug libraries in “smart pump” systems. In addition to the reduction of medication administration errors, this integration may also increase caregiver productivity and provide more contextual information regarding infusion data. + +Electronic transfer of infusion information from a pump to a clinical information system once an infusion has started can be accomplished using the Communicate PCD Data [PCD-01] or Subscribe to PCD Data [PCD-02]) transactions of the IHE DEV Device Enterprise Communication (DEC) Profile, as well as the Communicate Infusion Event Data [PCD-10] transaction of the IHE DEV Infusion Pump Event Communication (IPEC) Profile. + +The profile includes the following steps (note that the workflow supported by the BCMA application may not necessarily occur in the order specified): + +* Clinician uses BCMA to administer an IV +* Clinician identifies self, medication, patient, pump +* Clinician confirms or edits infusion parameters for an IV medication order using the BCMA +* Infusion parameters are transmitted to pump +* Clinician confirms settings directly on pump and starts infusion + +==== PIV Process Flow + +Figure 4.3-1 shows the sequence diagram for this profile. + +Figure 4.3-1: Basic Process Flow in Point-of-Care Infusion Verification Profile + +=== Use Cases + +The PIV Profile supports the following use cases: + +*New bag/syringe/container* + +*Subsequent bag/syringe/container of same medication* + +An infusion order that is used to program an initial or subsequent bag, syringe or other container. + +*Rate change or titration of an existing infusion* + +An order specifying a titration or change of rate on an existing infusion. + +*Patient controlled analgesia (PCA)* + +A PCA order for an initial or subsequent bag, syringe or other container on a PCA pump with complete settings including + +[arabic] +. Loading dose (initial bolus) +. Patient dose (PCA dose, patient bolus) +. Lockout interval (lockout time) +. Continuous rate (basal rate) +. Dose limit (per hour, per x hours) + +*Bolus from an existing infusion* + +A bolus can be programmed under the following conditions: + +* An infusion is currently programmed on the pump. +* A bolus of the same medication is ordered (i.e., there is a new order in the EHR). +* The EHR workflow provides the nurse the capability to administer the bolus from the same bag or syringe using the PIV [PCD-03] transaction to send the bolus order to the pump. +* No assumption is made about the behavior of the pump once the bolus has been delivered. Depending on the pump type or model it may stop, alarm, or resume delivering the underlying infusion. + +*Multistep* + +Multistep refers to a type of program that can deliver a single medication and concentration in a sequence of 2 or more steps where each step may contain different settings for rate, dose, dosing unit, VTBI, and/or duration depending on the pump model. + +*Example 1 – Cyclic TPN* + +Medication – TPN 1000 mL + +Step 1 – 25 mL/hr x 1 hr + +Step 2 – 50 mL/hr x 1 hr + +Step 3 – 100 mLhr x 6 hr + +Step 4 – 50 mL/hr x 1 hr + +Step 5 – 25 mL/hr x 1 hr + +image:extracted-media-tf1/media/image4.png[extracted-media-tf1/media/image4,width=480,height=288] + +*Example 2 - Initial dose followed by continuous infusion* + +Medication – Drug A 500 mg/500 mL + +Step 1 – 50 mg over 30 min (100 mg/hr) + +Step 2 – 10 mg/hr + +Note: Step 1 in this example is sometimes referred to as a “bolus” or “loading dose”. + +image:extracted-media-tf1/media/image5.png[extracted-media-tf1/media/image5,width=480,height=288] + +*Supported use cases* + +Programming a new multistep infusion + +Programming a new infusion with an initial bolus or loading dose + +*Excluded use cases* + +* Ramp/taper modes +* Initial bolus or loading dose of the same medication with a _different_ concentration +* Other types of bolus doses +* Change of dose, rate, or other delivery parameters of one or more steps in a confirmed multistep program + +* Some pump models may support changing manually. + +* Adding or removing a step to a confirmed multistep program + +* Some pump models may support manual addition or deletion of a step. + +* Cancelling or clearing a confirmed multistep program + +* Done manually on pump by user. + +=== Integration Profile Safety and Security Considerations + +This profile relies on the BCMA system to verify the clinician and patient, as well as the correct medication and infusion parameters, prior to initiating the Communicate Infusion Order transaction. + +Although the profile provides infusion settings for an infusion pump, the infusion is not started automatically. The clinician must always verify all settings and start the infusion directly on the pump. + +== Implantable Device – Cardiac – Observation (IDCO) + +Cardiac physicians follow patients with implantable cardiac devices from multiple manufacturers. These devices are categorized as implantable pacemakers, cardioverter defibrillators, cardiac resynchronization therapy devices, and implantable cardiac monitor devices. As part of patient follow-up an interrogation of an implanted cardiac device is performed (either in-clinic or remotely from a patient’s residence). These initial device interrogations (solicited or unsolicited) are typically performed by manufacturer provided interrogation equipment using manufacturer specific protocols. Information is collected regarding the implanted device (attributes, settings and status), the patient (demographics and observations) and therapy (delivery and results). + +To improve workflow efficiencies cardiology and electrophysiology practices require the management of “key” information in a central system such as an EHR or a device clinic management system. + +To address this requirement, the Implantable Device – Cardiac – Observation (IDCO) Profile defines a standards based translation and transfer of summary device interrogation information from the manufacturer provided interrogation equipment to the information management system. + +The IDCO Profile specifies a mechanism for the translation, transmission, processing, and storage of discrete data elements and report attachments associated with cardiac device interrogations (observations). + +=== IDCO Actors and Transactions + +Figure 5.1-1 shows the actors directly involved in the IDCO Integration Profile and the relevant transactions between them. Other actors that may be indirectly involved due to their participation in other related profiles are not necessarily shown. + +image:extracted-media-tf1/media/image6.emf[extracted-media-tf1/media/image6] + +Figure 5.1-1: IDCO Actor Diagram + +See Section 5.5 Patient Identification for details concerning how patient identity is managed. + +Table 5.1-1 lists the transactions for each actor directly involved in the IDCO Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options defined by this Integration Profile and that implementations may choose to support is listed in Volume 1, Section 5.2. + +Table 5.1-1: IDCO Integration Profile - Actors and Transactions + +[width="100%",cols="31%,37%,16%,16%",options="header",] +|=== +|Actors |Transactions |Optionality |Section in Volume 2 +|Implantable Device – Cardiac – Reporter |Communicate IDC Observation [PCD-09] |R |3.9 +|Implantable Device – Cardiac – Consumer |Communicate IDC Observation [PCD-09] |R |3.9 +|=== + +=== IDCO Integration Profile Options + +Options that may be selected for this Integration Profile are listed in the Table 5.2-1 along with the actors to which they apply. Dependencies between options when applicable are specified in notes. + +Table 5.2-1: IDCO - Actors and Options + +[width="100%",cols="36%,46%,18%",options="header",] +|=== +|Actor |Options |Section in Volume 2 +|Implantable Device – Cardiac – Reporter |PV1 – Patient Visit |3.9.4.1.2.3 +| |OBX – Encapsulated PDF or Reference Pointer |3.9.4.1.2.7 +|Implantable Device – Cardiac – Consumer |PV1 – Patient Visit |3.9.4.1.2.3 +| |OBX – Encapsulated PDF or Reference Pointer |3.9.4.1.2.7 +|=== + +Patient Visit Option – Because this is an unsolicited observation and the Implantable Device – Cardiac – Reporter will not be aware of an associated order, this segment is optional. The Implantable Device – Cardiac – Reporter may want to track the interrogation as a visit using this segment. + +Encapsulated PDF or Reference Pointer Option - observations or additional analyses may be provided in an encapsulated PDF containing displayable information or as a reference pointer to an external report. + +=== IDCO Use Cases + +==== Use Case IDCO-1: Implantable Cardiac Device In-Clinic Follow-up + +*Clinical Context:* + +Alex Everyman presents at the implantable cardiac device follow-up clinic for his appointment. Alex will present for follow-up 7-10 days after implant and every 3-6 months thereafter, depending on the therapy protocol. + +Dr. Tom Electrode, a cardiac physician, and Nicci Nightingale, a registered nurse (R.N.), work in the implantable cardiac device follow-up clinic. + +Nicci interrogates the device using a cardiac device programmer. The programmer extracts the device data (e.g., settings, status, events) from the device. Nicci reviews and verifies the device data and initiates a transfer of the data from the programmer to a translator system. A necessary subset of the data that represents a summary is converted by the translator system from a proprietary data format to a standard HL7 format. The data is then transmitted using HL7 messaging to the EHR or device clinic management system. + +This summary data is sent as an unsolicited observation message. + +Notes: + +[arabic] +. In the area of Electrophysiology, a "programmer" is a commonly used term to describe a specialized computer that is capable of communicating with an implanted device. Programmers are used to interrogate implanted devices (as are “interrogators”) and "program", or make changes to the cardiac device settings. +. In this use case, the translator system is a clinical information computer system that can receive proprietary structured data from the programmer and perform the necessary transformation and communication protocols to communicate effectively with the EMR. +. Electrocardiograms are not currently addressed in the HL7 standards. They can be sent as a PDF attachment to the HL7 message. + +*IHE Context:* + +In the use case, the translator system equates to the Implantable Device – Cardiac – Reporter and the EHR or device clinic management system equates to the Implantable Device – Cardiac – Consumer. The HL7 formatted cardiac device message is the [PCD-09] transaction. + +==== Use Case IDCO2: Implantable Cardiac Device In-Clinic Follow-up with Networked Programmer that Translates Information + +*Clinical Context:* + +Same as in-clinic use case above with the following change. The programmer communicates directly with an EHR or device clinic management system, acting as a translator system. + +*IHE Context:* + +Same as in-clinic use case above with the following change. The programmer assumes the role the actor Implantable Device – Cardiac – Reporter. + +==== Use Case IDCO-3: Implantable Cardiac Device Remote Follow-up + +*Clinical Context:* + +Portions of the previous use case also apply to Alex Everyman having his device followed remotely. Alex will present to an interrogation device located outside of the clinic (e.g., in Alex’s residence) which will capture the state of his implanted device and will transmit the information to a translator system. The translator system converts the data into an HL7 message and communicates the summary data to the clinic's EHR. + +*IHE Context:* + +Same as in-clinic use case 5.3.1 above. It is recommended that the Implantable Device – Cardiac – Reporter be grouped with the Secure Node of the ATNA Profile to secure communications for remote follow-ups if data is sent across an un-trusted network. + +==== Use Case IDCO-4: Remote Monitoring of Implanted Cardiac Devices + +*Clinical Context:* + +The translator system described in use case IDCO-3 may be implemented as a service, e.g., the device manufacturer or a monitoring service. This system may collect data provided on a periodic basis to enable early detection of trends and problems, or provide other event information. This system may also provide various types of value-added services, such as data aggregation and analysis, trending, statistical reports, and the ability to review and verify data before sending to the EMR. Depending on user selectable settings in the translator system, detailed information concerning the current status of the patient and reports may be sent to the recipient system. + +*IHE Context:* + +The same as the Remote Follow-up use case above. The additional data aggregation or rendering can be sent as a PDF attachment to the HL7 message. + +These types of value-added services are likely to be provided by a party that will send the results over the Internet. It is recommended that the Implantable Device – Cardiac – Reporter be grouped with the Secure Node of the ATNA Profile to secure communications for remote follow-ups if data is sent across an un-trusted network. + +=== IDCO Process Flow + +image:extracted-media-tf1/media/image7.emf[extracted-media-tf1/media/image7] + +Figure 5.4-1: Basic Process Flow in IDCO Profile + +Note: Device, Interrogator, and steps 1 thru 4, 6 and 7 are informative and are not formal actors or transactions of the IDCO Profile. + +[arabic] +. Send Interrogation – The Device sends information in a manufacturer-proprietary manner to the Interrogator. + +[arabic, start=6] +. Send Interrogation – The Interrogator sends information in a manufacturer-proprietary manner to the Implantable Device – Cardiac – Reporter. +. Validate and Review – The Implantable Device – Cardiac – Reporter validates the information. This may include the clinician reviewing and approving the information. +. Translate Information – The Implantable Device – Cardiac – Reporter translates/maps/transforms the information into the proper HL7 format. +. Send Observation – The Implantable Device – Cardiac – Reporter sends the device information to the Observation Consumer using the [PCD-09] transaction. +. Receive Observation – The Implantable Device – Cardiac – Consumer receives the observation message. +. Process Observation – The Implantable Device – Cardiac – Consumer further processes the observation message for inclusion within derivative products, such as clinical reports, databases, or trans-coded / reformatted results. + +=== IDCO Patient Identification Considerations + +This profile assumes a pre-coordinated association of identifiers across the two Patient Identifier Domains: the device manufacturer systems providing the observations and the clinics receiving the observations. + +Depending on local regulations, each implantable cardiac device manufacturer may be obligated to maintain a registry that maps a unique device identifier with the patient in which it is implanted. In some locales, this mapping is the strict responsibility of the implanting or other organization. Specific patient identification information is typically not stored in the device but is made available in the registry or by other means. Consequently, the Implantable Device – Cardiac – Reporter is only required to send this identifier which represents the patient to device relationship for an implanted device as part of the [PCD-09] transaction. This identifier by normative convention is the concatenation of a unique industry wide manufacturer id, unique manufacturer model number, and unique manufacturer serial number. + +This profile specifies one actor, the Implantable Device – Cardiac – Consumer, as the endpoint for observation messages. The Implantable Device – Cardiac – Consumer will have pre-coordinated a cross-reference of patient identifiers across the two Patient Identifier Domains. This will be done by storing the unique device identifier within the patient’s record. This will typically be the patient’s unique identity but could be the patient’s location in emergency situations. + +In some cases, the Implantable Device – Cardiac – Reporter will have detailed patient identification information like name, address, etc. In these cases, the Implantable Device – Cardiac – Reporter can send this information as part of the [PCD-09] transaction. + +=== IDCO Security Considerations + +This profile does not require the use of ATNA. There are several implementation models for this profile that do not require transmission of data over public networks including intra-institutional, VPN, etc. However, when public networks are used, ATNA is one option for secure transport over those networks. It is recommended that the Implantable Device – Cardiac – Reporter be grouped with the Secure Node of the ATNA Profile to secure communications for remote follow-ups if data is sent across an un-trusted network. + +== Alert Communication Management (ACM) Integration Profile + +Alert Communication Management defines the communication of alerts (physiologic alarms, technical alarms, and advisories) from alert reporting systems to alert consumer or alert manager systems and from alert manager systems to alert communicator systems. + +Figure 6-1: What is an Alert? + +This is an alert (alarms and advisories) distribution solution providing the following: + +* Communication from an alert gateway to an alert consumer, manager, or distributor +* Communication to an alert communicator for dissemination to people using both wired and wireless communication devices, typically clinicians, physicians, or other healthcare staff, for responding to patient needs or related workflows + +The primary use of the IHE DEV Alert Communications Management (ACM) Profile is to serve in communication of alert information from alert reporting systems, such as patient care devices, location service systems (LS/RTLS/RFID), or equipment management systems (CMMS/CEMS) to an alert manager system communicating with additional means of notification to caregivers. Notification devices would include those capable of supporting this profile, in particular [PCD-06] and [PCD-07]. + +Consolidation of alerts is out of scope for this profile. + +The definition of escalation actions in response to a notification not being responded to is outside the scope of this profile. + +=== ACM Actors and Transactions + +Figure 6.1-1 shows the actors directly involved in the ACM Integration Profile and the relevant transactions between them. Other actors that may be indirectly involved due to their participation in other related profiles, etc. are not necessarily shown. + +Figure 6.1-1: ACM Profile Actor Diagram + +Table 6.1-1 lists the transactions for each actor directly involved in the ACM Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options defined by this Integration Profile and that implementations may choose to support is listed in Section 6.2. + +Table 6.1-1: ACM Integration Profile – Actors and Transactions + +[width="100%",cols="22%,37%,13%,15%,13%",options="header",] +|=== +|Actors |Transactions |Direction |Optionality |Section in Vol. 2 +|Alert Reporter (AR) |Report Alert [PCD-04] |Outbound |R |3.4 +| |Report Alert Status [PCD-05] |Inbound |O |3.5 +|Alert Manager (AM) |Report Alert [PCD-04] |Inbound |R |3.4 +| |Disseminate Alert [PCD-06] |Outbound |R |3.6 +| |Report Dissemination Alert Status [PCD-07] |Inbound |R |3.7 +| |Report Alert Status [PCD-05] |Outbound |O |3.5 +|Alert Consumer |Report Alert [PCD-04] |Inbound |R |3.7 +|Alert Communicator (AC) |Disseminate Alert [PCD-06] |Inbound |R |3.6 +| |Report Dissemination Alert Status [PCD-07] |Outbound |R |3.7 +|=== + +Evidentiary data for ECG or other physiological waveforms are defined in a separate format specification, Waveform Content Module (WCM). WCM evidentiary data can optionally be included in ACM Report Alert [PCD-04] messages and optionally processed by the Alert Manager into evidentiary data and/or graphical snippet attachments to the Disseminate Alert [PCD-06] message. + +The capability for the Alert Manager to optionally synthesize a static graphical snippet and provide that to the Alert Communicator is provided so that the Alert Communicator can avoid implementing the algorithms needed to synthesize the graphical snippet from the HL7 evidentiary data. + +Figure 6.1-2: ACM Profile Actor Diagram + +=== ACM Integration Profile Options + +Options that may be selected for the ACM Integration Profile are listed in Table 6.2-1 ACM Actor Options along with the actors to which they apply. + +Through use of the Disseminate and Report Alert Status Option, an ACM Alert Manager, Alert Communicator, and its population of endpoint communication devices can be shared between HL7 v2.6 based Alert Reporter Actors of the ACM Profile and FHIR DSTU2 based Alert Reporters of the ITI mACM Profile. An Alert Consumer can make use of this option and it does not affect its lack of requirement for support of communication with an Alert Communicator (AC). For definitions of ITI mACM actors and transactions, and for mapping of FHIR data items to ACM PCD-04 HL7 v2.6 data items, refer to the ITI mACM Profile. + +Table 6.2-1: ACM Actor Options + +[width="100%",cols="12%,71%,17%",options="header",] +|=== +|Actor |Options a| +Section in + +Volume 2 + +|AR |May send additional alert notification recipients in [PCD-04] |B.7.1.1 +|AR |Receives Report Alert Status in [PCD-05] |B.7.1.1 +|AR |Can send WCM data in [PCD-04] |B.7.1.1 +|AM |Processes additional alert notification recipients in [PCD-04] |B.7.1.1 +|AM |Sends Report Alert Status in [PCD-05] |B.7.1.1 +|AM |Can send WCM data from PCD-04 in [PCD-06] |B.7.1.1 +|AM |Can send WCM [PCD-04] based data as graphical snippet in [PCD-06] |B.7.1.1 +|ACON |Can receive WCM data in [PCD-04] |B.7.1.1 +|AC |Can receive WCM evidentiary data in [PCD-06] and present graphics |B.7.1.1 +|AC |Can receive WCM graphics snippet in [PCD-06] and present it |B.7.1.1 +|AM |Disseminate and Report Alert Status (in support of ITI mACM) |B.7.1.1 +|ACON |Disseminate and Report Alert Status (in support of ITI mACM) |B.7.1.1 +|=== + +If protocol specific proper default processing is performed in Alert Manager for HL7 and in Alert Communicator for WCTP implementations there should be no need for the above transaction specific options. The options are for Connectathon vendor actor matching to identify WCM specific capability testing partners. + +=== Actor Descriptions + +==== Alert Reporter (AR) Actor + +This actor originates the alert (an alarm, either physiological or technical, or an advisory). + +The semantics and data types used to represent alert type, alert priority, alert inactivation state and escalation and de-escalation of priority in the messages of this actor are based on IEC 60601-1-8 definitions. + +The Alert Reporter (AR) is responsible for receiving optional Report Alert Status [PCD-05] transactions sent by the Alert Manager (AM). The [PCD-05] transaction serves to inform the Alert Reporter (AR) as to alert notification recipients (who and/or communication device), delivery confirmation status, read receipt, and endpoint communication device operator responses. + +Receipt of Report Alert Status [PCD-05] transactions shall at a minimum be logged. How the Alert Reporter (AR) responds to Report Alert Status [PCD-05] transactions besides logging is beyond the scope of the ACM Profile. + +The Alert Reporter can optionally include WCM evidentiary data in the Report Alert [PCD-04] message. + +A single source can produce multiple, possibly concurrent, alerts. + +A single Report Alert transaction can contain at most a single alert. + +This profile specifies the required data and data types produced by this actor. + +This profile specifies communication of the data produced by this actor. + +This actor may optionally cancel an outstanding alert condition. + +This may optionally indicate cancellation of any related escalation. + +An outstanding alert condition may be optionally escalated via follow-on alert. + +This actor may aggregate and adapt alerts from multiple sources as needed to make them interoperable with the Alert Manager. It does not need to be the original source of the alert data. + +In large alert source populations, an aggregation system may be useful for concentration and possible alert coordination (smart alerting). + +==== Alert Manager (AM) Actor + +This actor receives alerts from the Alert Reporter, manages them, and dispatches them to the Alert Communicator. + +The semantics and data types used to represent alert type, alert priority, alert inactivation state and escalation and de-escalation of priority in the messages of this actor are based on IEC 60601-1-8 definitions. + +The Alert Manager (AM) is responsible for sending optional Report Alert Status [PCD-05] transactions to the Alert Reporter (AR) as a result of alert notification dissemination status updates received from the Alert Communicator (AC) in Report Dissemination Alert Status [PCD-07] transactions. The [PCD-05] transaction serves to inform the Alert Reporter (AR) as to alert notification recipients (who and/or communication device), delivery confirmation status, read receipt, and endpoint communication device operator responses. + +There is a one-to-many nature of the [PCD-04] transaction into many [PCD-05] transactions. A single [PCD-04] transaction from the Alert Reporter to the Alert Manager can be sent to multiple recipients. Think of unit-wide code alert notifications (which could be tens of recipients) or a clinician and their buddies (typically two recipients). This results in multiple [PCD-06] transactions from the Alert Manager to the Alert Communicator. Each [PCD-06] transaction from the Alert Manager to the Alert Communicator can result in multiple [PCD-07] dissemination and reply status updates from the Alert Communicator back to the Alert Manager. + +The Alert Manager may take WCM evidentiary data from the Report Alert [PCD-04] message and optionally send that to the Alert Communicator (AC) as WCTP message attachments in the Disseminate Alert [PCD-06] message as either or both of the original [PCD-04] message in its entirety or as a graphical snippet synthesized by the Alert Manager into a graphical snippet. + +This profile specifies the required data and data types produced by this actor in communication with the Alert Communicator and Alert Reporter Actors. + +If the following is performed, it is likely performed within the Alert Manager. + +* Alert formatting for dissemination +* Alert harmonization across multiple similar and dissimilar Alert Reporter +* Any additional alert priority actions following any performed by the Alert Reporter +* Alert mapping of recipients to Alert Communicator endpoints, +* Additional recipients are optionally indicated in the Report Alert [PCD-04] transaction +* Alert dissemination escalation +* Alert dissemination sequencing to Alert Communicator endpoints +* Alert dissemination escalation to Alert Communicator endpoints +* Location to staff assignments +* Patient identification to staff assignments +* Equipment to patient to staff assignments +* Staff to Alert Communicator endpoint assignments +* Alert reporting +* Alert caching + +To accomplish assignments the Alert Manager may receive HL7 ADT or SCH message feeds from one or more sourcing systems for the following purposes: + +* Identify patients +* Assign resources to patients (staff, equipment, rooms) + +This profile specifies the required data and data types produced by this actor. + +The protocol used in the communication of the data to/from the Alert Manager (AM) and the Alert Communicator (AC) is the Wireless Communication Transfer Protocol (WCTP). + +==== Alert Consumer (ACON) Actor + +Alert Consumer – The Alert Consumer (ACON) receives the alert from the Alert Reporter (AR) and uses the alert information strictly as a consumer of the alert being raised. + +The Alert Consumer may receive WCM evidentiary data from the Report Alert [PCD-04] message. + +There is no implementation requirement for how the Alert Consumer ultimately uses the alert information. + +==== Alert Communicator (AC) Actor + +The Alert Communicator (AC) is not responsible for taking action in the event that the endpoint operator has received but not responded to the notification. Actions for non-response by the Alert Communicator (AC) endpoint operator (clinical user) are within the scope of the Alert Manager (AM). These actions are commonly referred to as escalation whether it is repeatedly sending the same message to the same recipient or to alternate recipients. The definition of such actions has been identified as out-of-scope for the ACM Profile. + +The Alert Communicator (AC) receives alerts from the Alert Manager (AM). Endpoint devices are connected either directly or indirectly to the Alert Communicator (AC). The Alert Communicator (AC) may utilize a locally controlled or public infrastructure. + +The protocol for communication between the Alert Manager (AM) and the Alert Communicator (AC) shall be WCTP. + +The Alert Communicator may optionally take WCM related WCTP attachments from the Disseminate Alert [PCD-06] message and display an attached graphical snippet with appropriate and display data safe scaling to fit the display of the endpoint communication device or may take content from an evidentiary data attachment and synthesize an endpoint communication device display appropriate waveform graphical snippet and display it on the device. + +The capability for the Alert Manager to optionally synthesize a static graphical snippet and provide that to the Alert Communicator is provided so that the Alert Communicator doesn’t have to implement the algorithms needed to synthesize the graphical snippet from the HL7 evidentiary data. + +This profile does not specify the protocol used in the communication of the data to the final destination as it is potentially not controllable by the Alert Communicator (AC). + +This profile does not specify the presentation of the data at the endpoint as that is beyond its control. + +This profile does not specify the human interface at the endpoint as that is beyond its control. + +This profile does make recommendations as to the significant data items to be included in alert notifications with consideration for ePHI (electronic Patient Healthcare Information). The correlation of what data items are to be sent for specific alerts is defined in IHE DEV Profiles in conjunction with alert inclusion in the IHE DEV Rosetta Terminology Mapping (RTM) activities. + +It is recognized that in healthcare communication there are certain data items which should not be transported over unsecured and unencrypted communication connections. A number of controls come into play including HIPAA requirements and ePHI guidelines. It is the responsibility of the deploying parties to insure that capabilities are put into place and monitored to assure that information protection requirements are met. + +WCTP was originally defined by the Personal Communications Industry Association (PCIA) consortium. The PCIA is not an SDO and is not at this time actively sustaining or enhancing WCTP. WCTP is in popular and stable use by a number of wide area communication service providers. The protocol provides the capabilities required by Alert Manager to Alert Communicator communication, specifically Internet common practice recognized HTTP or HTTPS securable application to application communication, reliable TCP/IP transport, extensible XML data envelope, transactions for application to individual person communication, and communication status responses for closed loop confirmations for delivery to Alert Communicator (AC), delivery to endpoint device, read by device operator, and operator responses. With permission from the PCIA, this ACM Profile includes and adopts version 1.3 update 1 of the WCTP protocol as defined by PCIA at http://www.wctp.org[www.wctp.org] for use in Alert Manager (AC) to Alert Communicator (AC) communication. Corrections and extensions to this capture of the protocol are the responsibility of the Alert Communication Management (ACM) Working Group (WG) within the Devices (DEV) domain of IHE. As the protocol has been in live operation with major communication carriers for some time, the risk of changes required for corrective actions is perceived as low. The protocol includes defined areas for client-server agreed two-party extensions. The ACM Profile will make use of that capability as needs arise. + +Not all of the WCTP protocol possible request/response transactions are required for Alert Manager (AM) to Alert Communicator (AC) communication. Later sections of this document identify the specifics. + +=== ACM Use Cases + +Alert Communication Management is meant to improve clinical efficiency by using technology to deliver the right alerts, with the right priority, to the right individuals via devices with the right content, and through configuration escalating communication of alerts to devices associated with other individuals. + +The following are the use cases. The use cases are noticeably generic and not so much focused on the alert clinical purpose as they are focused on the system interactions. The use cases may be directly applicable to other IHE domains, and may be supplemented with additional use cases to serve specific needs in other domains. + +Figure 6.4.1-1: Basic Process Flow in ACM Profile + +==== ACM Process Flow + +Each actor is identified below. Actor identity is implicitly identified in the alert (for example, through MSH-21 Message Profile, identifying the message as [PCD-04] by OID, which is sent by an ACM Alert Reporter, which is identified in MSH-3 Sending Application). + +The functional units comprising an actor may be provided by one or more vendors in one or more systems. Reducing the total number of systems is preferred, but is not required. + +Data flow of individual use model messaging communication indicates the command response sequences and directions. + +==== ACM Use Cases + +===== Case A1: Location Sourced + +Use Case – Patient wants a pillow. Patient pulls nurse call. Nurse call system lights the room’s dome light and light at central station. Nurse call system, operating as an Alert Reporter (AR) sends Report Alert [PCD-04] to Alert Manager (AM) indicating nurse call alert. The Alert Manager (AM) logs receipt of the alert. The Alert Manager (AM) identifies the appropriate nurse based upon configured nurse to patient assignments, identifies the appropriate Alert Communicator (AC) and destination communication device based upon nurse to device configuration in Alert Manager (AM), sends Disseminate Alert [PCD-06] to nurse’s communication device. The Alert Manager (AM) logs the dissemination to the Alert Communicator (AC). The Alert Manager (AM) sends a Report Alert Status [PCD-05] to the Alert Reporter (AR) to inform the Alert Reporter (AR) of the status of the communication of the alert to the Alert Communication (AC) which may indicate successfully sent or not. The nurse receives the alert on their assigned device. The information minimally includes the patient location (room number). The Alert Manager (AM) sends a Report Alert Status [PCD-05] to the Alert Reporter (AR) to inform the Alert Reporter (AR) of the delivery confirmation status which may indicate delivered or not delivered. The nurse replies to the alert on the communication device, the Alert Communicator (AC) sends a Report Dissemination Alert Status [PCD-07] to the Alert Manager (AM). The Alert Manager (AM) sends a Report Alert Status [PCD-05] to the Alert Reporter (AR) to inform the Alert Reporter (AR) of the nurse response to the alert notification. The nurse goes to the room, determines the needs of the patient, and provides the patient with a pillow. The nurse then resets the nurse call pull. The nurse call system turns off the room’s dome light and the light at the central station. The nurse call system, operating as an Alert Reporter (AR) sends Report Alert [PCD-04] to Alert Manager (AM) indicating reset of the nurse call alert. The Alert Manager (AM) receives the alert turns off any configured alert escalation and logs the alert. + +===== Case A2: Identified Patient Source + +Use Case – Alert occurs on PCD assigned to patient. PCD or PCD gateway system, operating as an Alert Reporter (AR) sends Report Alert [PCD-04] to Alert Manager (AM) indicating PCD alert. The Alert Manager (AM) logs receipt of the alert. The Alert Manager (AM) identifies the appropriate nurse based upon configured nurse to patient assignments, identifies the appropriate Alert Communicator (AC) and destination communication device based upon nurse to device configuration in Alert Manager (AM), sends Disseminate Alert [PCD-06] to nurse’s communication device. The Alert Manager (AM) logs the dissemination to the Alert Communicator (AC). The Alert Manager (AM) sends a Report Alert Status [PCD-05] to the Alert Reporter (AR) to inform the Alert Reporter (AR) of the status of the communication of the alert to the Alert Communication (AC) which may indicate successfully sent or not. The nurse receives the alert on their assigned device. The information minimally includes the patient identification. The Alert Manager (AM) sends a Report Alert Status [PCD-05] to the Alert Reporter (AR) to inform the Alert Reporter (AR) of the delivery confirmation status which may indicate delivered or not delivered. The nurse replies to the alert on the communication device, the Alert Communicator (AC) sends a Report Dissemination Alert Status [PCD-07] to the Alert Manager (AM). The Alert Manager (AM) sends a Report Alert Status [PCD-05] to the Alert Reporter (AR) to inform the Alert Reporter (AR) of the nurse response to the alert notification. The nurse goes to the room, determines the needs of the patient, and responds to the PCD alert. The nurse then clears the PCD alert. The PCD or PCD gateway system, operating as an Alert Reporter (AR) sends Report Alert [PCD-04] to Alert Manager (AM) indicating reset of the PCD alert. The Alert Manager (AM) receives the alert turns off any configured alert escalation and logs the alert. + +===== Case A3: Same as A1/A2 with Escalation with Cancel at Alert Source + +Use Case 3: (same as use case 1 or 2 with escalation with cancel at source) if the communication destination is inaccessible or the target individual is indicated as unavailable, then the alert is rerouted to one or more alternatives with escalation to higher levels of responsibility until the alert is canceled at its source and the alert system notified of the cancel. + +===== Case A4: Same as A1/A2 with Escalation with Cancel at Communication Endpoint + +Use Case 4: (same as use case 1 or 2 with escalation with cancel of any active Alert Manager (AM) escalation actions at communication endpoint) if the communication destination is inaccessible or the target individual is indicated as unavailable then the alert is rerouted to one or more alternatives with escalation to higher levels of responsibility until the alert is canceled by a recipient at a communication endpoint. + +===== Case A5: Same as A1/A2 with Escalation with Cancel at Alert Manager + +Use Case 5: (same as use case 1 or 2 with escalation with cancel of any active Alert Manager (AM) escalation actions at alert management system) if the communication destination is inaccessible or the target individual is indicated as unavailable then the alert is rerouted to one or more alternatives with escalation to higher levels of responsibility until the alert is canceled by a user on the Alert Manager (AM), however not automatically via algorithms in the Alert Manager (AM). + +===== Case A6: Information with no destination other than logging by the Alert Manager (AM) or Alert Consumer Actor + +Use Case 6: The use case for this is to log information from the Alert Reporter (AR) with the Alert Manager (AM) and not to disseminate the information to the Alert Communicator (AC). The information can be information meant to be used in concert with alerts received from the Alert Reporter (AR), or for logs or information not meant for dissemination to users, but used in reporting alert environment after the fact. + +This is also applicable to the Alert Consumer (ACon) actor where there is no presumption of any Disseminate Alert [PCD-06] message generation. + +This is also applicable to the Alert Consumer (ACon) actor where there is no presumption of any Disseminate Alert [PCD-06] message generation. + +===== Case A7: Equipment Sourced Alert + +Use Case 7: The use case for this alert is to communicate medical equipment management events from devices when those events are not patient focused, such as battery low or failure to charge or malfunctioning of alerts. Such indications are device specific, patient independent, and potentially location independent. + +=== ACM Security Considerations + +This profile itself does not impose specific requirements for authentication, encryption, or auditing, leaving these matters to site-specific policy or agreement. The IHE DEV Technical Framework identifies security requirements across all DEV profiles. + +== Infusion Pump Event Communication (IPEC) Integration Profile + +The Infusion Pump Event Communication (IPEC) Profile is based on the general observation reporting in the Device Enterprise Communication (DEC) Profile. Infusion Pump Event Communication uses the same general form of interactions among Device Observation Reporter and Device Observation Consumer Actors. + +The principal intended uses of IHE Device Enterprise Communication in acute care are to communicate device data to enterprise information systems for: + +* Reporting, charting and trending physiological data to assist clinicians in tracking the patients physiological state for situational awareness and care planning +* Near-real-time response to clinically or technically actionable events and situations +* Provision of information for an archival record of device observations, possibly including events, that are clinical, technical, or both + +Device Enterprise Communications (DEC) is chiefly designed for the first goal listed based on periodic observation reporting, but has always provided for episodic and event reporting as a subtype of general event reporting. + +The Infusion Pump Event Communication Integration Profile is designed to address the third goal of reporting events, specifically infusion pump events. It defines a means for communicating significant events related to medication administration by infusion pumps. + +*Events in Medical Device Communications* + +An event, in the context of medical device communications, is an occurrence about which it is desired to communicate information between devices and information systems. Events are communicated as soon after their occurrence as is technically feasible, in contrast to other observation reporting from devices to information systems which capture the trend of continuously-varying physiological characteristics indicating the patient’s clinical status by communicating observations at regular time intervals. These characteristics are usually then displayed to clinical users in a spreadsheet-like grid or on a trend graph. + +One special sort of event is an episodic measurement, that is, one that is not automatically initiated on a regular, timed basis, such as a spot blood pressure cuff reading, or a non-continuous cardiac output measurement. These are initiated manually and the receiving information system has no foreknowledge of when they will occur. + +Another special case is an alarm or advisory, where the key outcome of the alert is meant to be some action by a person. The Alert Communication Management (ACM) Profile is focused on the human notification aspect of this. + +*Relation of Infusion Pump Event Communication to Alert Communication Management (ACM) Profile* + +_See the https://www.ihe.net/resources/technical_frameworks/#GenIntro[IHE Technical Frameworks General Introduction Appendix D: Glossary] for definitions of the terms Advisory, Alarm, and Alert._ + +Alert Communication Management has provided expanded formats with additional attributes for alarms and advisories, with emphasis on transmitting the information to specific individuals who need to be notified at the point of care via portable devices. For purposes of this discussion, a distinction is made between events and alerts. + +* Events are operational milestones and key parameter changes. For example, during normal execution of an infusion therapy, non-alarm conditions such as start of delivery, change of rate, switchover from piggyback to primary drug, completion of delivery, transition to KVO, etc. are important to full recording or state awareness for the therapeutic process. +* Alerts, which are distinct from events and are intended to engage a response from the clinician, are supported by the Alert Communication Management Profile. + +Clinical information systems must communicate, for real-time high-reliability review and action, and record for documentation purposes: + +* Exception Events – physiological or technical, which may indicate conditions either in the patient or in the equipment in use by those caring for the patient, which need attention at stated levels of urgency. These include alarms, appropriately processed for human notification using the Alert Communication Management Profile, but may in addition need to be communicated to information systems for other purposes than immediate notification of persons, such as documentation. +* State transitions – operationally significant changes between discrete states of physiological or technical conditions (for example, “modes” and “settings” for a device, “warning or alarm limit” or “action limit” for a measured physiological parameter). +* Priority may be evaluated by the original sending device or by business rules and clinical protocols in downstream systems. Sources for raw and derived data and interpretations of priority must be documented for audit/forensic purposes, potentially by additions to content of message. + +=== Actors/Transactions + +Figure 7.1-1 shows the actors directly involved in the Infusion Pump Event Communication Integration Profile and the relevant transactions between them. Other actors that may be indirectly involved due to their participation in Device Enterprise Communications (DEC) or Point-of-care Infusion Verification (PIV), etc., are not necessarily shown. + +image:extracted-media-tf1/media/image8.png[extracted-media-tf1/media/image8,width=624,height=374] + +Figure 7.1-1: Infusion Pump Event Communication Actor Diagram + +Table 7.1-1 lists the transactions for each actor directly involved in the Infusion Pump Event Communication Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” are optional. + +Table 7.1-1: Infusion Pump Event Communication Integration Profile - Actors and Transactions + +[width="100%",cols="31%,32%,16%,21%",options="header",] +|=== +|Actors |Transactions |Optionality |Section in Vol. 2 +|Device Observation Reporter |Communicate Infusion Event Data |R |3.10 +|Device Observation Consumer |Communicate Infusion Event Data |R |3.10 +|=== + +=== IPEC Options + +The Infusion Pump Event Communication Profile does not define any options. + +=== IPEC Actor Groupings and Profile Interactions + +None + +=== Infusion Pump Event Communication Process Flow + +==== Standard Use Cases + +===== Case IPEC-1: Communicate event data to EMR/EHR + +Data from all of the patient care devices associated with a particular patient is communicated by a Gateway, Device or Clinical Information System (CIS) implementing the DOR Actor to an EMR/EHR, implementing the DOC Actor. This document only covers event data received from infusion pumps. Discrete parameters representing the device’s state at or near the time of the event are included. The data is time stamped with a consistent time across the data from the respective patient care devices. + +The primary intent is communication of structured data; however, provisions are made for inclusion of unstructured data. The application provides facilities to bind an authoritative enterprise patient identifier required for inclusion of the PCD data in the patient record. The workflow for associating the authoritative enterprise patient identifier to the PCD data is outside the scope of the current DEV TF. + +image:extracted-media-tf1/media/image10.png[extracted-media-tf1/media/image10,width=576,height=339] + +Figure 7.4.1.1-1: Basic Process Flow in Infusion Pump Event Communication Profile + +=== IPEC Security Considerations + +The IPEC Profile does not address issues of privacy, security, and confidentiality associated with cross-enterprise communication of PCD data. The assumption is made that the IPEC Profile is implemented in a single enterprise on a secure network. + +[#_Toc181620157 .anchor]####Appendices + +== Appendix A Rosetta Terminology Mapping (RTM) + +=== A.1 Problem Statement + +The majority of PCD devices use vendor-specific or proprietary nomenclatures and terminologies. As a result, even though information may be exchanged using standards-based transactions such as Device Enterprise Communication (DEC), semantic interoperability requires that the content be mapped to a standard nomenclature as well. This mapping is often inconsistent and subject to loss of semantic precision when mapping from a specific term to a more generic term. + +The RTM value set identifies the core set of semantics appropriate for medical devices typically used in acute care settings (e.g., physiological monitors, ventilators, infusion pumps, etc.) and mapping them to a standard terminology. The RTM mapping effort initially focused on numeric parameters and their associated units of measurement and enumerated values. The RTM mapping effort currently is focused on numeric parameters and associated units of measure and enumerated values, and will likely be expanded to include aspects of the observation hierarchy expressed in OBR-4 and event content models in the future. + +The RTM information is represented in a uniform manner e.g., in a machine-readable form that is easily adaptable by industry, as a set of Excel worksheets and a set of XML files for publication and distribution. This will facilitate use by production systems, but more importantly, facilitate comparison between vendors that have (or will) implement the nomenclature standards in their systems, with the following goals: + +* identify terms that are missing from the standard nomenclature +* ensure correct and consistent use if multiple representations are possible +* ensure correct and consistent use of units-of-measure +* ensure correct and consistent use of enumerated values +* ensure correct and consistent identification of ‘containment hierarchy’ + +During the development of the RTM and later, gaps in the standardized medical device terminology will be identified. In these cases, proposals will be made for adding the semantics to the appropriate terminologies. Although the immediate focus of the RTM will be to standardize the content in transaction profiles such as DEC, which are typically between a device data gateway and enterprise level applications, the standardized terms should also support direct device communication, enabling semantic interoperability literally from the sensor to the EHR. + +The availability of the RTM information will also facilitate development of tools that can more rigorously validate messages, such as enforcing the use of the correct units-of-measure and correct enumerated values associated with specific numeric values. For example, ST segment deviation will be expressed in "uV" or "mV", rather than the traditional "mm". This will promote greater interoperability, clarity and correctness which will in turn benefit patient safety. + +The consistent and correct use of standard nomenclatures such as ISO/IEEE 11073-10101 and UCUM for medical device and system data exchange will facilitate further development of real-time clinical decision support, smart alarms, safety interlocks, clinical algorithms, and data mining and other clinical research. This work can also be expanded at a future date to support events and alarms, waveforms, device settings and other critical monitoring information. + +=== A.2 Key Use Case + +A patient is monitored at home. A potentially life-threatening cardiac event is detected and reported to a remote monitoring service that confirms and forwards the event to his caregiver. The patient is subsequently admitted to the ER complaining about chest pain. A diagnostic 12-lead is taken followed by continuous vital signs monitoring or telemetry for further observation. Following a series of premonitory episodes of ST segment deviation, the patient exhibits short runs of ventricular ectopy that rapidly devolve into ventricular tachycardia and then fibrillation, all along triggering alarms from the monitor. The patient is cardioverted in the ER and scheduled for CABG surgery. During surgery, the patient is connected to well over a dozen medical devices (e.g., multiparameter patient monitor, anesthesia machine, multiple infusion pumps, bypass machine, etc.) and the data from these devices and systems is displayed in a unified and comprehensible manner and automatically charted. After successful surgery, the patient is monitored in the ICU. The patient is discharged a week later to continue his recovery at home, where, among other things, he uses a spirometer with a low-cost wireless interface to facilitate recovery. He also exercises while walking around inside and outside the house attached to a wireless sensor that records and transmits his ECG via his cell phone to a remote monitoring service. The patient also has follow-up visits to cardiac rehab, where his ECG and glucose measurements are taken before and after exercise, with all the data also electronically recorded. This information is ultimately stored in the patient's personal health record and made available for a follow-up clinical research study regarding the cardiac medications he was taking. + +The key point of this comprehensive but realistic use case is that the patient's data is "touched" by well over three dozen medical devices and systems designed and manufactured by nearly an equal number of different vendors. An essential first step towards achieving interoperability across all these devices and systems is that they use a shared and common semantic foundation. + +== Glossary + +Please see the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-D.html[Appendix D - Glossary] for the IHE Glossary. diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image1.jpeg b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image1.jpeg new file mode 100644 index 0000000..4459cc0 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image1.jpeg differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image10.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image10.emf new file mode 100644 index 0000000..ccd3ddd Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image10.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image11.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image11.emf new file mode 100644 index 0000000..4d42cd9 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image11.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image12.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image12.emf new file mode 100644 index 0000000..82eaffb Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image12.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image13.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image13.emf new file mode 100644 index 0000000..f3b6cd6 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image13.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image14.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image14.emf new file mode 100644 index 0000000..71ed2bd Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image14.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image15.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image15.emf new file mode 100644 index 0000000..766d2b2 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image15.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image16.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image16.emf new file mode 100644 index 0000000..2dc6b87 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image16.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image17.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image17.emf new file mode 100644 index 0000000..d92d2ba Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image17.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image18.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image18.emf new file mode 100644 index 0000000..afa973f Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image18.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image2.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image2.png new file mode 100644 index 0000000..33ae85a Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image2.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image3.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image3.png new file mode 100644 index 0000000..7e73fd2 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image3.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image31.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image31.emf new file mode 100644 index 0000000..c85caf4 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image31.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image32.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image32.emf new file mode 100644 index 0000000..81a40a0 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image32.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image33.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image33.emf new file mode 100644 index 0000000..4fe7867 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image33.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image34.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image34.emf new file mode 100644 index 0000000..9e3d37f Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image34.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image35.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image35.png new file mode 100644 index 0000000..04b1121 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image35.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image36.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image36.png new file mode 100644 index 0000000..8f81fa0 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image36.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image37.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image37.png new file mode 100644 index 0000000..5d88414 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image37.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image38.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image38.png new file mode 100644 index 0000000..58f4100 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image38.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image39.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image39.png new file mode 100644 index 0000000..59aade6 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image39.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image4.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image4.png new file mode 100644 index 0000000..1abb490 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image4.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image40.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image40.emf new file mode 100644 index 0000000..007fa68 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image40.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image41.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image41.png new file mode 100644 index 0000000..c5429bc Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image41.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image42.jpeg b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image42.jpeg new file mode 100644 index 0000000..c791e34 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image42.jpeg differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image43.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image43.png new file mode 100644 index 0000000..0ef93bd Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image43.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image44.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image44.png new file mode 100644 index 0000000..70c6df6 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image44.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image45.png b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image45.png new file mode 100644 index 0000000..8f541b5 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image45.png differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image46.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image46.emf new file mode 100644 index 0000000..53fd633 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image46.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image47.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image47.emf new file mode 100644 index 0000000..f1d60e6 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image47.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image48.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image48.emf new file mode 100644 index 0000000..74c903c Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image48.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image49.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image49.emf new file mode 100644 index 0000000..893d143 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image49.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image5.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image5.emf new file mode 100644 index 0000000..6ce2933 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image5.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image6.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image6.emf new file mode 100644 index 0000000..ccde5f8 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image6.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image7.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image7.emf new file mode 100644 index 0000000..f01521b Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image7.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image8.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image8.emf new file mode 100644 index 0000000..fe7e634 Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image8.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image9.emf b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image9.emf new file mode 100644 index 0000000..672365c Binary files /dev/null and b/Technical Frameworks/AsciiDoc Source/tf2/extracted-media-tf2/media/image9.emf differ diff --git a/Technical Frameworks/AsciiDoc Source/tf2/tf2.adoc b/Technical Frameworks/AsciiDoc Source/tf2/tf2.adoc new file mode 100644 index 0000000..d9c37b7 --- /dev/null +++ b/Technical Frameworks/AsciiDoc Source/tf2/tf2.adoc @@ -0,0 +1,9828 @@ +*Integrating the Healthcare Enterprise* + +image:extracted-media-tf2/media/image1.jpeg[IHE_LOGO_for_tf-docs,width=171,height=88] + +IHE Devices (DEV) + +Technical Framework + +Volume 2 + +IHE DEV TF-2 + +Transactions + +*Revision 10.0 – Final Text* + +*November 4, 2024* + +*Please verify you have the most recent version of this document,* which is published https://profiles.ihe.net/DEV/index.html[here]. + +*CONTENTS* + +link:#introduction[1 Introduction link:#introduction[8]] + +link:#introduction-to-ihe[1.1 Introduction to IHE link:#introduction-to-ihe[8]] + +link:#intended-audience[1.2 Intended Audience link:#intended-audience[8]] + +link:#overview-of-technical-framework-volume-2[1.3 Overview of Technical Framework Volume 2 link:#overview-of-technical-framework-volume-2[8]] + +link:#comment-process[1.4 Comment Process link:#comment-process[9]] + +link:#copyright-licenses[1.5 Copyright Licenses link:#copyright-licenses[9]] + +link:#_Toc181625088[1.6 Trademark link:#_Toc181625088[9]] + +link:#disclaimer-regarding-patent-rights[1.7 Disclaimer Regarding Patent Rights link:#disclaimer-regarding-patent-rights[9]] + +link:#history-of-document-changes[1.8 History of Document Changes link:#history-of-document-changes[10]] + +link:#conventions[2 Conventions link:#conventions[12]] + +link:#transaction-modeling-and-profiling-conventions[2.1 Transaction Modeling and Profiling Conventions link:#transaction-modeling-and-profiling-conventions[12]] + +link:#additional-standards-profiling-conventions[2.2 Additional Standards Profiling Conventions link:#additional-standards-profiling-conventions[12]] + +link:#use-of-coded-entities-and-coding-schemes[2.3 Use of Coded Entities and Coding Schemes link:#use-of-coded-entities-and-coding-schemes[12]] + +link:#ihe-devices-transactions[3 IHE Devices Transactions link:#ihe-devices-transactions[13]] + +link:#communicate-pcd-data-pcd-01[3.1 Communicate PCD Data [PCD-01] link:#communicate-pcd-data-pcd-01[13]] + +link:#scope[3.1.1 Scope link:#scope[13]] + +link:#use-case-roles[3.1.2 Use Case Roles link:#use-case-roles[13]] + +link:#referenced-standards[3.1.3 Referenced Standards link:#referenced-standards[14]] + +link:#messages[3.1.4 Messages link:#messages[14]] + +link:#dor-communicates-with-doc[3.1.4.1 DOR communicates with DOC link:#dor-communicates-with-doc[14]] + +link:#pcd-01-communicate-pcd-data-orur01oru_r01-static-definition[3.1.4.1.1 PCD-01 Communicate PCD Data (ORU^R01^ORU_R01) static definition link:#pcd-01-communicate-pcd-data-orur01oru_r01-static-definition[15]] + +link:#trigger-events[3.1.4.1.2 Trigger events link:#trigger-events[16]] + +link:#message-semantics[3.1.4.1.3 Message Semantics link:#message-semantics[17]] + +link:#expected-actions[3.1.4.1.4 Expected Actions link:#expected-actions[17]] + +link:#security-considerations[3.1.5 Security Considerations link:#security-considerations[17]] + +link:#pcd-02-reserved[3.2 [PCD-02] Reserved link:#pcd-02-reserved[18]] + +link:#communicate-infusion-order-pcd-03[3.3 Communicate Infusion Order [PCD-03] link:#communicate-infusion-order-pcd-03[18]] + +link:#scope-1[3.3.1 Scope link:#scope-1[18]] + +link:#use-case-roles-1[3.3.2 Use Case Roles link:#use-case-roles-1[18]] + +link:#referenced-standards-1[3.3.3 Referenced Standards link:#referenced-standards-1[18]] + +link:#messages-1[3.3.4 Messages link:#messages-1[18]] + +link:#pcd-03-communicate-infusion-order-rgvo15rgv_o15-static-definition[3.3.4.1 PCD-03 Communicate Infusion Order (RGV^O15^RGV_O15) static definition link:#pcd-03-communicate-infusion-order-rgvo15rgv_o15-static-definition[19]] + +link:#rgvo15rgv_o15-pharmacytreatment-give-message[3.3.4.2 RGV^O15^RGV_O15 Pharmacy/Treatment Give Message link:#rgvo15rgv_o15-pharmacytreatment-give-message[19]] + +link:#trigger-events-1[3.3.4.3 Trigger Events link:#trigger-events-1[21]] + +link:#message-semantics-1[3.3.4.4 Message Semantics link:#message-semantics-1[21]] + +link:#msh-message-header-segment[3.3.4.4.1 MSH – Message Header Segment link:#msh-message-header-segment[21]] + +link:++#pid---patient-identification-segment++[3.3.4.4.2 PID - Patient Identification Segment link:++#pid---patient-identification-segment++[23]] + +link:#pv1-patient-visit-segment[3.3.4.4.3 PV1 Patient Visit Segment link:#pv1-patient-visit-segment[23]] + +link:++#orc---common-order-segment++[3.3.4.4.4 ORC - Common Order Segment link:++#orc---common-order-segment++[23]] + +link:++#rxg---pharmacytreatment-give-segment++[3.3.4.4.5 RXG - Pharmacy/Treatment Give Segment link:++#rxg---pharmacytreatment-give-segment++[23]] + +link:#usage-notes-for-rxg-17-18-23-and-24[3.3.4.4.6 Usage notes for RXG 17, 18, 23, and 24 link:#usage-notes-for-rxg-17-18-23-and-24[28]] + +link:#tq1-timing-quantity-segment[3.3.4.4.7 TQ1 Timing Quantity Segment link:#tq1-timing-quantity-segment[30]] + +link:++#rxr---pharmacytreatment-route-segment++[3.3.4.4.8 RXR - Pharmacy/Treatment Route Segment link:++#rxr---pharmacytreatment-route-segment++[32]] + +link:++#obx---observationresult-segment++[3.3.4.4.9 OBX - Observation/Result segment link:++#obx---observationresult-segment++[33]] + +link:#rate-change-titration-bolus-from-existing-infusion-and-multistep[3.3.4.4.10 Rate change, titration, Bolus from existing infusion, and Multistep link:#rate-change-titration-bolus-from-existing-infusion-and-multistep[38]] + +link:#rate-change-or-titration[3.3.4.4.10.1 Rate change or titration link:#rate-change-or-titration[38]] + +link:#bolus-from-existing-infusion[3.3.4.4.10.2 Bolus from existing infusion link:#bolus-from-existing-infusion[38]] + +link:#multistep[3.3.4.4.10.3 Multistep link:#multistep[39]] + +link:#expected-actions-1[3.3.4.4.11 Expected Actions link:#expected-actions-1[41]] + +link:#rrgo16rrg_o16-pharmacytreatment-give-acknowledgement-message[3.3.5 RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgement Message link:#rrgo16rrg_o16-pharmacytreatment-give-acknowledgement-message[42]] + +link:#msh-message-header-segment-1[3.3.5.1 MSH – Message Header Segment link:#msh-message-header-segment-1[43]] + +link:++#msa---message-acknowledgement-segment++[3.3.5.2 MSA - Message Acknowledgement segment link:++#msa---message-acknowledgement-segment++[43]] + +link:++#err---error-segment++[3.3.5.3 ERR - Error segment link:++#err---error-segment++[43]] + +link:#report-alert-pcd-04[3.4 Report Alert [PCD-04] link:#report-alert-pcd-04[43]] + +link:#scope-2[3.4.1 Scope link:#scope-2[43]] + +link:#use-case-roles-2[3.4.2 Use Case Roles link:#use-case-roles-2[44]] + +link:#referenced-standards-2[3.4.3 Referenced Standards link:#referenced-standards-2[44]] + +link:#messages-2[3.4.4 Messages link:#messages-2[45]] + +link:#alert-reporter-reports-to-alert-manageralert-consumer[3.4.4.1 Alert Reporter reports to Alert Manager/Alert Consumer link:#alert-reporter-reports-to-alert-manageralert-consumer[45]] + +link:#hl7-conformance-statement[3.4.4.1.1 HL7 Conformance Statement link:#hl7-conformance-statement[45]] + +link:#pcd-04-report-alert-orur40oru_r40-static-definition[3.4.4.1.2 PCD-04 Report Alert (ORU^R40^ORU_R40) static definition link:#pcd-04-report-alert-orur40oru_r40-static-definition[45]] + +link:#trigger-events-2[3.4.4.1.3 Trigger Events link:#trigger-events-2[47]] + +link:#message-semantics-2[3.4.4.1.4 Message Semantics link:#message-semantics-2[47]] + +link:#expected-actions-2[3.4.4.1.5 Expected Actions link:#expected-actions-2[48]] + +link:#security-considerations-1[3.4.4.1.6 Security Considerations link:#security-considerations-1[48]] + +link:#report-alert-status-pcd-05[3.5 Report Alert Status [PCD-05] link:#report-alert-status-pcd-05[49]] + +link:#scope-3[3.5.1 Scope link:#scope-3[49]] + +link:#use-case-roles-3[3.5.2 Use Case Roles link:#use-case-roles-3[49]] + +link:#referenced-standard[3.5.3 Referenced Standard link:#referenced-standard[49]] + +link:#messages-3[3.5.4 Messages link:#messages-3[49]] + +link:#alert-manager-status-updates-to-alert-reporter[3.5.4.1 Alert Manager status updates to Alert Reporter link:#alert-manager-status-updates-to-alert-reporter[50]] + +link:#trigger-events-3[3.5.4.1.1 Trigger Events link:#trigger-events-3[50]] + +link:#message-semantics-3[3.5.4.1.2 Message Semantics link:#message-semantics-3[50]] + +link:#hl7-conformance-statement-1[3.5.4.1.3 HL7 Conformance Statement link:#hl7-conformance-statement-1[51]] + +link:#pcd-05-report-alert-status-orar41ora_r41-static-definition[3.5.4.1.4 PCD-05 Report Alert Status (ORA^R41^ORA_R41) static definition link:#pcd-05-report-alert-status-orar41ora_r41-static-definition[51]] + +link:#expected-actions-3[3.5.4.1.5 Expected Actions link:#expected-actions-3[53]] + +link:#security-considerations-2[3.5.4.1.6 Security Considerations link:#security-considerations-2[55]] + +link:#disseminate-alert-pcd-06[3.6 Disseminate Alert [PCD-06] link:#disseminate-alert-pcd-06[55]] + +link:#scope-4[3.6.1 Scope link:#scope-4[55]] + +link:#use-case-roles-4[3.6.2 Use Case Roles link:#use-case-roles-4[55]] + +link:#referenced-standard-1[3.6.3 Referenced Standard link:#referenced-standard-1[56]] + +link:#messages-4[3.6.4 Messages link:#messages-4[56]] + +link:#alert-manager-disseminate-alert-to-alert-communicator[3.6.4.1 Alert Manager disseminate alert to Alert Communicator link:#alert-manager-disseminate-alert-to-alert-communicator[56]] + +link:#hl7-conformance-statement-2[3.6.4.1.1 HL7 Conformance Statement link:#hl7-conformance-statement-2[56]] + +link:#pcd-06-disseminate-alert-static-definition[3.6.4.1.2 PCD-06 Disseminate Alert static definition link:#pcd-06-disseminate-alert-static-definition[56]] + +link:#trigger-events-4[3.6.4.1.3 Trigger Events link:#trigger-events-4[57]] + +link:#message-semantics-4[3.6.4.1.4 Message Semantics link:#message-semantics-4[57]] + +link:#_Toc181625170[3.6.4.1.5 Expected Actions link:#_Toc181625170[57]] + +link:#security-considerations-3[3.6.4.1.6 Security Considerations link:#security-considerations-3[58]] + +link:#report-dissemination-alert-status-pcd-07[3.7 Report Dissemination Alert Status [PCD-07] link:#report-dissemination-alert-status-pcd-07[58]] + +link:#scope-5[3.7.1 Scope link:#scope-5[58]] + +link:#use-case-roles-5[3.7.2 Use Case Roles link:#use-case-roles-5[58]] + +link:#_Toc181625175[3.7.3 Referenced Standards link:#_Toc181625175[59]] + +link:#messages-5[3.7.4 Messages link:#messages-5[59]] + +link:#alert-communicator-status-updates-to-alert-manager[3.7.4.1 Alert Communicator status updates to Alert Manager link:#alert-communicator-status-updates-to-alert-manager[59]] + +link:#trigger-events-5[3.7.4.2 Trigger Events link:#trigger-events-5[59]] + +link:#message-semantics-5[3.7.4.2.1 Message Semantics link:#message-semantics-5[61]] + +link:#hl7-conformance-statement-3[3.7.4.2.2 HL7 Conformance Statement link:#hl7-conformance-statement-3[61]] + +link:#pcd-07-report-dissemination-alert-status-static-definition[3.7.4.2.3 PCD-07 Report Dissemination Alert Status static definition link:#pcd-07-report-dissemination-alert-status-static-definition[61]] + +link:#expected-actions-5[3.7.4.2.4 Expected Actions link:#expected-actions-5[61]] + +link:#security-considerations-4[3.7.4.2.5 Security Considerations link:#security-considerations-4[62]] + +link:#pcd-08-reserved[3.8 [PCD-08] Reserved link:#pcd-08-reserved[62]] + +link:#communicate-idc-observations-pcd-09[3.9 Communicate IDC Observations [PCD-09] link:#communicate-idc-observations-pcd-09[62]] + +link:#scope-6[3.9.1 Scope link:#scope-6[62]] + +link:#use-case-roles-6[3.9.2 Use Case Roles link:#use-case-roles-6[62]] + +link:#referenced-standard-2[3.9.3 Referenced Standard link:#referenced-standard-2[63]] + +link:#messages-6[3.9.4 Messages link:#messages-6[63]] + +link:#hl7-oru-observation[3.9.4.1 HL7 ORU Observation link:#hl7-oru-observation[64]] + +link:#trigger-events-6[3.9.4.1.1 Trigger Events link:#trigger-events-6[64]] + +link:#message-semantics-6[3.9.4.1.2 Message Semantics link:#message-semantics-6[64]] + +link:#msh-segment-message-header[3.9.4.1.2.1 MSH Segment – Message Header link:#msh-segment-message-header[65]] + +link:#pid-segment-patient-identification[3.9.4.1.2.2 PID Segment – Patient Identification link:#pid-segment-patient-identification[66]] + +link:#pv1-segment-patient-visit-optional[3.9.4.1.2.3 PV1 Segment – Patient Visit (Optional) link:#pv1-segment-patient-visit-optional[68]] + +link:#obr-segment-observation-request[3.9.4.1.2.4 OBR Segment – Observation Request link:#obr-segment-observation-request[68]] + +link:#obx-segments-pulse-generator-and-lead-observation-results[3.9.4.1.2.5 OBX Segments – Pulse Generator and Lead Observation Results link:#obx-segments-pulse-generator-and-lead-observation-results[70]] + +link:#ieee-1073.1.1.3-idc-term-mapping-to-obx-segment[3.9.4.1.2.6 IEEE 1073.1.1.3 IDC term mapping to OBX segment link:#ieee-1073.1.1.3-idc-term-mapping-to-obx-segment[73]] + +link:#obx-segment-with-encapsulated-pdf-or-reference-pointer-to-external-report-optional[3.9.4.1.2.7 OBX Segment with Encapsulated PDF or Reference Pointer to External Report [Optional] link:#obx-segment-with-encapsulated-pdf-or-reference-pointer-to-external-report-optional[73]] + +link:#nte-segment-notes-and-comments-optional[3.9.4.1.2.8 NTE Segment – Notes and Comments [Optional] link:#nte-segment-notes-and-comments-optional[75]] + +link:#expected-actions-6[3.9.4.1.3 Expected Actions link:#expected-actions-6[76]] + +link:#implantable-device-cardiac-consumer[3.9.4.1.3.1 Implantable Device – Cardiac – Consumer link:#implantable-device-cardiac-consumer[76]] + +link:#security-considerations-5[3.9.5 Security Considerations link:#security-considerations-5[76]] + +link:#communicate-infusion-event-data-pcd-10[3.10 Communicate Infusion Event Data [PCD-10] link:#communicate-infusion-event-data-pcd-10[76]] + +link:#scope-7[3.10.1 Scope link:#scope-7[76]] + +link:#use-case-roles-7[3.10.2 Use Case Roles link:#use-case-roles-7[76]] + +link:#referenced-standard-3[3.10.3 Referenced Standard link:#referenced-standard-3[77]] + +link:#messages-7[3.10.4 Messages link:#messages-7[78]] + +link:#_Toc181625209[3.10.4.1 Communicate Infusion Event Data link:#_Toc181625209[78]] + +link:#trigger-events-7[3.10.4.1.1 Trigger Events link:#trigger-events-7[78]] + +link:#message-semantics-7[3.10.4.1.2 Message Semantics link:#message-semantics-7[78]] + +link:#expected-actions-7[3.10.4.1.3 Expected Actions link:#expected-actions-7[79]] + +link:#_Toc181625213[Appendices link:#_Toc181625213[80]] + +link:#appendix-a-mapping-isoieee-11073-domain-information-model-to-hl7[Appendix A Mapping ISO/IEEE 11073 Domain Information Model to HL7 link:#appendix-a-mapping-isoieee-11073-domain-information-model-to-hl7[81]] + +link:#a.1-isoieee-nomenclature-mapping-to-hl7-obx-3[A.1 ISO/IEEE Nomenclature mapping to HL7 OBX-3 link:#a.1-isoieee-nomenclature-mapping-to-hl7-obx-3[84]] + +link:#appendix-b-common-segment-descriptions[Appendix B Common Segment Descriptions link:#appendix-b-common-segment-descriptions[86]] + +link:#b.1-msh-message-header-segment[B.1 MSH – Message Header Segment link:#b.1-msh-message-header-segment[86]] + +link:#b.2-msa-message-acknowledgement-segment[B.2 MSA – Message Acknowledgement Segment link:#b.2-msa-message-acknowledgement-segment[91]] + +link:#b.3-err-error-segment[B.3 ERR – Error Segment link:#b.3-err-error-segment[92]] + +link:++#b.4-nte---notes-and-comment-segment++[B.4 NTE - Notes and Comment Segment link:++#b.4-nte---notes-and-comment-segment++[96]] + +link:++#b.5-pid---patient-identification-segment++[B.5 PID - Patient Identification segment link:++#b.5-pid---patient-identification-segment++[97]] + +link:#b.5.1-pid-segment-requirements-for-acm-transaction-pcd-04[B.5.1 PID Segment requirements for ACM Transaction PCD-04 link:#b.5.1-pid-segment-requirements-for-acm-transaction-pcd-04[104]] + +link:++#b.6-pv1---patient-visit-segment++[B.6 PV1 - Patient Visit Segment link:++#b.6-pv1---patient-visit-segment++[105]] + +link:#b.6.1-pv1-patient-visit-segment-in-acm-transaction-pcd-04[B.6.1 PV1 Patient Visit Segment in ACM Transaction PCD-04 link:#b.6.1-pv1-patient-visit-segment-in-acm-transaction-pcd-04[108]] + +link:#b.7-obr-observation-request-segment[B.7 OBR – Observation Request segment link:#b.7-obr-observation-request-segment[108]] + +link:#b.7.1-obr-observation-request-segment-in-acm-transaction-pcd-04[B.7.1 OBR Observation Request Segment in ACM Transaction [PCD-04] link:#b.7.1-obr-observation-request-segment-in-acm-transaction-pcd-04[116]] + +link:#b.8-obx-observation-result-segment[B.8 OBX – Observation Result Segment link:#b.8-obx-observation-result-segment[117]] + +link:#b.8.1-obx-4-in-a-flattened-representation-of-a-device[B.8.1 OBX-4 in a 'flattened' representation of a device link:#b.8.1-obx-4-in-a-flattened-representation-of-a-device[120]] + +link:#b.8.2-obx-4-in-a-hierarchical-representation-of-a-device[B.8.2 OBX-4 in a hierarchical representation of a device link:#b.8.2-obx-4-in-a-hierarchical-representation-of-a-device[120]] + +link:#b.8.3-device-related-and-metric-related-obx-segments-in-hierarchy-are-tied-together-by-their-obx-4-values[B.8.3 'Device-related' and 'metric-related' OBX segments in hierarchy are tied together by their OBX-4 values link:#b.8.3-device-related-and-metric-related-obx-segments-in-hierarchy-are-tied-together-by-their-obx-4-values[120]] + +link:#b.8.4-dictionary-ordering-of-device-related-and-metric-related-obx-segments[B.8.4 Dictionary ordering of 'device-related' and 'metric-related' OBX segments link:#b.8.4-dictionary-ordering-of-device-related-and-metric-related-obx-segments[122]] + +link:#b.8.5-obx-4-sub-id-in-alert-communication-management-transactions-pcd-04-pcd-06-pcd-07[B.8.5 OBX-4 Sub-id in Alert Communication Management transactions ([PCD-04], [PCD-06], [PCD-07]) link:#b.8.5-obx-4-sub-id-in-alert-communication-management-transactions-pcd-04-pcd-06-pcd-07[123]] + +link:#b.8.6-obx-11-observation-result-status-in-report-alert-pcd-04[B.8.6 OBX-11 Observation Result Status in Report Alert [PCD-04] link:#b.8.6-obx-11-observation-result-status-in-report-alert-pcd-04[137]] + +link:#b.8.7-time-stamps-and-time-synchronization[B.8.7 Time Stamps and Time Synchronization link:#b.8.7-time-stamps-and-time-synchronization[141]] + +link:#b.8.8-device-time-synchronization-capabilities[B.8.8 Device Time Synchronization Capabilities link:#b.8.8-device-time-synchronization-capabilities[143]] + +link:#b.8.9-device-andor-dor-synchronization-protocol[B.8.9 Device and/or DOR Synchronization Protocol link:#b.8.9-device-andor-dor-synchronization-protocol[144]] + +link:#b.9-orc-common-order-segment[B.9 ORC – Common Order Segment link:#b.9-orc-common-order-segment[145]] + +link:#b.9.1-orc-observation-control-segment-in-acm-transaction-pcd-04[B.9.1 ORC Observation Control Segment in ACM Transaction [PCD-04] link:#b.9.1-orc-observation-control-segment-in-acm-transaction-pcd-04[149]] + +link:#b.9.2-orc-observation-control-segment-in-piv-application-acknowledgment-rrgo16rrg_o16-pharmacytreatment-give-acknowledgement[B.9.2 ORC Observation Control Segment in PIV Application Acknowledgment (RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgement) link:#b.9.2-orc-observation-control-segment-in-piv-application-acknowledgment-rrgo16rrg_o16-pharmacytreatment-give-acknowledgement[150]] + +link:#b.10-prt-participation-information-segment[B.10 PRT Participation Information Segment link:#b.10-prt-participation-information-segment[150]] + +link:#b.10.1-prt-participation-information-segment-in-acm-transaction-pcd-04[B.10.1 PRT Participation Information Segment in ACM Transaction [PCD-04] link:#b.10.1-prt-participation-information-segment-in-acm-transaction-pcd-04[151]] + +link:#b.10.2-prt-participation-information-segment-in-acm-transaction-pcd-05[B.10.2 PRT Participation Information Segment in ACM Transaction [PCD-05] link:#b.10.2-prt-participation-information-segment-in-acm-transaction-pcd-05[154]] + +link:#b.10.3-future-prt-segment-use-to-support-unique-device-identifiers-in-the-pcd-profiles[B.10.3 Future PRT segment use to support Unique Device Identifiers in the PCD Profiles link:#b.10.3-future-prt-segment-use-to-support-unique-device-identifiers-in-the-pcd-profiles[157]] + +link:#appendix-c-common-data-types[Appendix C Common Data Types link:#appendix-c-common-data-types[171]] + +link:#c.1-cne-data-type-coded-with-no-exceptions[C.1 CNE Data Type – coded with no exceptions link:#c.1-cne-data-type-coded-with-no-exceptions[171]] + +link:#_Toc181625246[C.2 CWE Data Type – coded with exceptions link:#_Toc181625246[172]] + +link:#c.3-cx-data-type[C.3 CX Data Type link:#c.3-cx-data-type[173]] + +link:#c.4-dtm-datetime[C.4 DTM – date/time link:#c.4-dtm-datetime[173]] + +link:#c.5-entity-identifier-ei-data-type[C.5 Entity Identifier (EI) Data Type link:#c.5-entity-identifier-ei-data-type[174]] + +link:#c.6-hierarchic-designator-hd-data-type[C.6 Hierarchic Designator (HD) Data Type link:#c.6-hierarchic-designator-hd-data-type[176]] + +link:#c.7-pl-data-type[C.7 PL Data Type link:#c.7-pl-data-type[177]] + +link:#c.8-xpn-data-type[C.8 XPN Data Type link:#c.8-xpn-data-type[180]] + +link:#c.9-xtn-data-type[C.9 XTN Data Type link:#c.9-xtn-data-type[181]] + +link:#appendix-d-reserved[Appendix D Reserved link:#appendix-d-reserved[182]] + +link:#appendix-e-examples-of-messages[Appendix E Examples of Messages link:#appendix-e-examples-of-messages[183]] + +link:#e.1-pcd-01-case-c1-communicate-periodic-data-to-clinical-information-system-cis[E.1 PCD-01 Case C1: Communicate periodic data to Clinical Information System (CIS) link:#e.1-pcd-01-case-c1-communicate-periodic-data-to-clinical-information-system-cis[183]] + +link:#e.1.1-example-of-pcd-01-observation-report-physiological-monitor[E.1.1 Example of PCD-01 Observation Report (Physiological Monitor) link:#e.1.1-example-of-pcd-01-observation-report-physiological-monitor[183]] + +link:#e.1.2-example-of-pcd-01-episodic-observation-report[E.1.2 Example of PCD-01 Episodic Observation Report link:#e.1.2-example-of-pcd-01-episodic-observation-report[184]] + +link:#e.2-examples-of-transaction-pcd-03-communicate-infusion-order[E.2 Examples of transaction [PCD-03]: Communicate Infusion Order link:#e.2-examples-of-transaction-pcd-03-communicate-infusion-order[185]] + +link:#e.2.1-storyboard[E.2.1 Storyboard link:#e.2.1-storyboard[185]] + +link:#e.2.2-interaction-diagram[E.2.2 Interaction Diagram link:#e.2.2-interaction-diagram[186]] + +link:#e.2.3-messages[E.2.3 Messages link:#e.2.3-messages[187]] + +link:#e.3-acm-pcd-04-example-messages[E.3 ACM [PCD-04] Example Messages link:#e.3-acm-pcd-04-example-messages[189]] + +link:++#e.3.1-alert---numeric-limit-alarm++[E.3.1 Alert - Numeric Limit Alarm link:++#e.3.1-alert---numeric-limit-alarm++[189]] + +link:++#e.3.2-alert---qualitative-non-numeric-alarm++[E.3.2 Alert - Qualitative (non-numeric) Alarm link:++#e.3.2-alert---qualitative-non-numeric-alarm++[190]] + +link:#appendix-f-hl7-message-profiling-convention[Appendix F HL7 Message Profiling Convention link:#appendix-f-hl7-message-profiling-convention[192]] + +link:#appendix-g-hl7-implementation-notes[Appendix G – HL7 Implementation Notes link:#appendix-g-hl7-implementation-notes[193]] + +link:#g.1-acknowledgment-modes[G.1 Acknowledgment Modes link:#g.1-acknowledgment-modes[193]] + +link:#g.2-use-of-osi-object-identifier-oid[G.2 Use of OSI Object Identifier (OID) link:#g.2-use-of-osi-object-identifier-oid[193]] + +link:#appendix-h-ihe-integration-statements[Appendix H – IHE Integration Statements link:#appendix-h-ihe-integration-statements[194]] + +link:#appendix-i-message-transport-using-mllp[Appendix I – Message Transport using MLLP link:#appendix-i-message-transport-using-mllp[195]] + +link:#appendix-j-message-transport-using-ws[Appendix J – Message Transport using WS* link:#appendix-j-message-transport-using-ws[196]] + +link:#j.1-sample-wsdl-file-and-schema[J.1 Sample WSDL file and schema link:#j.1-sample-wsdl-file-and-schema[196]] + +link:#j.2-sample-pcd-01-message-and-response[J.2 Sample PCD-01 message and response link:#j.2-sample-pcd-01-message-and-response[198]] + +link:#appendix-k-message-transport-using-wctp-acm-transactions-pcd-06-and-pcd-07[Appendix K – Message Transport Using WCTP (ACM Transactions [PCD-06] and PCD-07) link:#appendix-k-message-transport-using-wctp-acm-transactions-pcd-06-and-pcd-07[201]] + +link:#k.1-abbreviations-and-definitions[K.1 Abbreviations and definitions link:#k.1-abbreviations-and-definitions[201]] + +link:#k.2-pre-configuration[K.2 Pre-Configuration link:#k.2-pre-configuration[201]] + +link:#k.3-endpoint-device-addressing[K.3 Endpoint Device Addressing link:#k.3-endpoint-device-addressing[201]] + +link:#k.4-polling-versus-push-responses[K.4 Polling Versus Push Responses link:#k.4-polling-versus-push-responses[201]] + +link:#k.5-constraints[K.5 Constraints link:#k.5-constraints[202]] + +link:#k.6-transactions[K.6 Transactions link:#k.6-transactions[202]] + +link:#k.7-wctp-xml-element-common-data-items[K.7 WCTP XML Element Common Data Items link:#k.7-wctp-xml-element-common-data-items[203]] + +link:#k.8-wctp-clientserver-messages-and-responses[K.8 WCTP client–server messages and responses link:#k.8-wctp-clientserver-messages-and-responses[208]] + +link:#k.8.1-administrative-wctp-versionquery[K.8.1 Administrative – wctp-VersionQuery link:#k.8.1-administrative-wctp-versionquery[209]] + +link:#k.8.2-administrative-wctp-versionresponse[K.8.2 Administrative – wctp-VersionResponse link:#k.8.2-administrative-wctp-versionresponse[209]] + +link:#_Toc181625286[K.8.3 Administrative – wctp-VersionResponse link:#_Toc181625286[209]] + +link:#k.8.4-ihe-pcd-06-wctp-submitrequest-no-mcr[K.8.4 IHE PCD-06 – wctp-SubmitRequest – no MCR link:#k.8.4-ihe-pcd-06-wctp-submitrequest-no-mcr[210]] + +link:#k.8.5-ihe-pcd-06-wctp-submitrequest-unpaired-mcr[K.8.5 IHE PCD-06 – wctp-SubmitRequest – Unpaired MCR link:#k.8.5-ihe-pcd-06-wctp-submitrequest-unpaired-mcr[210]] + +link:#k.8.6-ihe-pcd-06-wctp-submitrequest-paired-mcr[K.8.6 IHE PCD-06 – wctp-SubmitRequest – Paired MCR link:#k.8.6-ihe-pcd-06-wctp-submitrequest-paired-mcr[211]] + +link:#k.8.7-ihe-pcd-06-wctp-submitrequest-call-back-phone-number[K.8.7 IHE PCD-06 – wctp-SubmitRequest – Call Back Phone Number link:#k.8.7-ihe-pcd-06-wctp-submitrequest-call-back-phone-number[212]] + +link:#k.8.8-ihe-pcd-07-synchronous-response-to-wctp-submitrequest-received-by-communications-status-update[K.8.8 IHE PCD-07 – Synchronous response to wctp-SubmitRequest – Received by communications status update link:#k.8.8-ihe-pcd-07-synchronous-response-to-wctp-submitrequest-received-by-communications-status-update[213]] + +link:#k.8.9-wctp-pollformessages-general-poll-for-pre-connectathonvirtual-connectathon-testing[K.8.9 wctp-PollForMessages – general poll (for Pre-Connectathon/Virtual Connectathon testing) link:#k.8.9-wctp-pollformessages-general-poll-for-pre-connectathonvirtual-connectathon-testing[214]] + +link:#k.8.10-wctp-pollresponse-general-poll-for-pre-connectathonvirtual-connectathon-testing[K.8.10 wctp-PollResponse – general poll (for Pre-Connectathon/Virtual Connectathon testing) link:#k.8.10-wctp-pollresponse-general-poll-for-pre-connectathonvirtual-connectathon-testing[214]] + +link:#k.8.11-wctp-pollresponse-message-status-update-for-pre-connectathonvirtual-connectathon-testing[K.8.11 wctp-PollResponse message status update (for Pre-Connectathon/Virtual Connectathon testing) link:#k.8.11-wctp-pollresponse-message-status-update-for-pre-connectathonvirtual-connectathon-testing[215]] + +link:#k.8.12-wctp-pollresponse-message-status-update-acknowledgement-for-pre-connectathonvirtual-connectathon-testing[K.8.12 wctp-PollResponse message status update acknowledgement (for Pre-Connectathon/Virtual Connectathon testing) link:#k.8.12-wctp-pollresponse-message-status-update-acknowledgement-for-pre-connectathonvirtual-connectathon-testing[215]] + +link:#k.8.13-wctp-pollresponse-message-reply-not-in-response-to-an-mcr-based-wctp-submitrequest-for-pre-connectathonvirtual-connectathon-testing[K.8.13 wctp-PollResponse (message reply, not in response to an MCR based wctp-SubmitRequest) (for Pre-Connectathon/Virtual Connectathon testing) link:#k.8.13-wctp-pollresponse-message-reply-not-in-response-to-an-mcr-based-wctp-submitrequest-for-pre-connectathonvirtual-connectathon-testing[215]] + +link:++#k.8.14-ihe-pcd-07-asynchronous-status-update-delivered---delivery-confirmation++[K.8.14 IHE PCD-07 asynchronous status update (DELIVERED - delivery confirmation) link:++#k.8.14-ihe-pcd-07-asynchronous-status-update-delivered---delivery-confirmation++[216]] + +link:++#k.8.15-ihe-pcd-07-asynchronous-status-update-read---read-receipt++[K.8.15 IHE PCD-07 asynchronous status update (READ - read receipt) link:++#k.8.15-ihe-pcd-07-asynchronous-status-update-read---read-receipt++[216]] + +link:#k.8.16-ihe-pcd-07-asynchronous-reply-message-with-mcr-and-uri-response[K.8.16 IHE PCD-07 asynchronous reply message with MCR and URI response link:#k.8.16-ihe-pcd-07-asynchronous-reply-message-with-mcr-and-uri-response[217]] + +link:#k.8.17-ihe-dev-specific-wctp-extensions-to-pcd-06-wctp-submitrequest-for-wcm-attachments[K.8.17 IHE DEV specific WCTP extensions to PCD-06 wctp-SubmitRequest for WCM attachments link:#k.8.17-ihe-dev-specific-wctp-extensions-to-pcd-06-wctp-submitrequest-for-wcm-attachments[217]] + +link:#k.8.18-ihe-pcd-specific-wctp-extensions-to-wctp-submitrequest-for-alert-information[K.8.18 IHE PCD specific WCTP extensions to wctp-SubmitRequest for alert information link:#k.8.18-ihe-pcd-specific-wctp-extensions-to-wctp-submitrequest-for-alert-information[219]] + +link:#k.8.19-ihe-pcd-specific-wctp-extensions-to-pcd-07-transactions-for-alerts[K.8.19 IHE PCD specific WCTP extensions to PCD-07 transactions for alerts link:#k.8.19-ihe-pcd-specific-wctp-extensions-to-pcd-07-transactions-for-alerts[221]] + +link:#k.8.20-ihe-pcd-06-wctp-ihepcdsubmitrequestupdate[K.8.20 IHE PCD-06 wctp-IHEPCDSubmitRequestUpdate link:#k.8.20-ihe-pcd-06-wctp-ihepcdsubmitrequestupdate[222]] + +link:++#appendix-l---alert-alarm-fatigue++[Appendix L - Alert (Alarm) Fatigue link:++#appendix-l---alert-alarm-fatigue++[224]] + +link:#appendix-m-infusion-pump-events[Appendix M Infusion Pump Events link:#appendix-m-infusion-pump-events[226]] + +link:#m.1-basic-infusion-events[M.1 Basic Infusion Events link:#m.1-basic-infusion-events[226]] + +link:#_Toc181625307[M.1.1 Event Message – PCD-10 Communicate Infusion Event Data link:#_Toc181625307[228]] + +link:#m.1.2-infusion-pump-events[M.1.2 Infusion Pump Events link:#m.1.2-infusion-pump-events[229]] + +link:#m.1.2.1-infusion-event-parameters[M.1.2.1 Infusion Event Parameters link:#m.1.2.1-infusion-event-parameters[231]] + +link:#m.1.2.2-infusion-event-sample-message[M.1.2.2 Infusion Event Sample Message link:#m.1.2.2-infusion-event-sample-message[272]] + +link:#m.1.2.3-definition-of-pillarrackslot-topology[M.1.2.3 Definition of Pillar/Rack/Slot topology link:#m.1.2.3-definition-of-pillarrackslot-topology[274]] + +link:#m.1.2.3-specifying-a-pump-location-within-a-pillar-and-rack[M.1.2.3 Specifying a pump location within a Pillar (and Rack) link:#m.1.2.3-specifying-a-pump-location-within-a-pillar-and-rack[276]] + +link:#glossary[Glossary link:#glossary[283]] + +== Introduction + +This document, Volume 2 of the IHE Devices (DEV) Technical Framework, defines transactions used in IHE Patient Care Device profiles. + +=== Introduction to IHE + +Integrating the Healthcare Enterprise (IHE) is an international initiative to promote the use of standards to achieve interoperability among health information technology (HIT) systems and effective use of electronic health records (EHRs). IHE provides a forum for care providers, HIT experts and other stakeholders in several clinical and operational domains to reach consensus on standards-based solutions to critical interoperability issues. + +The primary output of IHE is system implementation guides, called IHE Profiles. IHE publishes each profile through a well-defined process of public review and trial implementation and gathers profiles that have reached final text status into an IHE Technical Framework, of which this volume is a part. + +For general information regarding IHE, refer to http://www.ihe.net[www.ihe.net]. It is strongly recommended that, prior to reading this volume, the reader familiarizes themselves with the concepts defined in the https://profiles.ihe.net/GeneralIntro/index.html[IHE Technical Frameworks General Introduction] + +=== Intended Audience + +The intended audience of IHE Devices Technical Framework Volume 2 is: + +* IT departments of healthcare institutions +* Technical staff of vendors participating in the IHE initiative +* Experts involved in standards development + +=== Overview of Technical Framework Volume 2 + +Volume 2 is comprised of several distinct sections: + +* Section 1 provides background and reference material. +* Section 2 presents the conventions used in this volume to define the transactions. +* Section 3 defines transactions in detail, specifying the roles for each actor, the standards employed, the information exchanged, and in some cases, implementation options for the transaction. + +The appendices in Volume 2 provide clarification of technical details of the IHE data model and transactions. Code and message samples may also be stored on the IHE Google Drive. In this case, explicit links to the applicable Google Drive folder will be provided in the transaction text. + +Due to the length of the document, some domains may divide Volume 2 into smaller volumes labeled 2a, 2b, etc. In this case, the Volume 2 appendices are gathered in Volume 2x. + +For a brief overview of additional Technical Framework Volumes (TF-1, TF-3, TF-4), please see the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-5.html[Section 5 - Structure of the IHE Technical Frameworks]. + +Code and message samples may also be stored on the IHE Google Drive. In this case, explicit links to Google Drive will be provided in the transaction text. + +=== Comment Process + +IHE International welcomes comments on this document and the IHE initiative. Comments on the IHE initiative can be submitted by sending an email to the co-chairs and secretary of the Devices domain committees at dev@ihe.net. Comments on this document can be submitted at http://ihe.net/Domain_acronym_Public_Comments. + +=== Copyright Licenses + +IHE technical documents refer to, and make use of, a number of standards developed and published by several standards development organizations. Please refer to the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-9.html[Section 9 - Copyright Licenses] for copyright license information for frequently referenced base standards. Information pertaining to the use of IHE International copyrighted materials is also available there. + +=== Trademark + +IHE® and the IHE logo are trademarks of the Healthcare Information Management Systems Society in the United States and trademarks of IHE Europe in the European Community. Please refer to the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-10.html[Section 10 - Trademark] for information on their use. + +=== Disclaimer Regarding Patent Rights + +Attention is called to the possibility that implementation of the specifications in this document may require use of subject matter covered by patent rights. By publication of this document, no position is taken with respect to the existence or validity of any patent rights in connection therewith. IHE International is not responsible for identifying Necessary Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of the specifications in this document are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information about the IHE International patent disclosure process including links to forms for making disclosures is available at http://www.ihe.net/Patent_Disclosure_Process/[[.underline]#http://www.ihe.net/Patent_Disclosure_Process#]. Please address questions about the patent disclosure process to the secretary of the IHE International Board: mailto:secretary@ihe.net[[.underline]#secretary@ihe.net#]. + +=== History of Document Changes + +This section provides a brief summary of changes and additions to this document. + +[width="100%",cols="16%,13%,71%",options="header",] +|=== +|Date |Document Revision |Change Summary +|2014-11-04 |4.0 |Incorporated approved Change Proposals Nos. 86-106 excluding withdrawn proposals. Integrated Sections 1 and 2 from 2014 Technical Framework Vol. 2 Templates and deleted material from Appendices which are now included by reference from the General Introduction. IHE Glossary is now included by reference. +|2015-10-14 |5.0 |Updated ACM Profile to include all approved CPs and for housekeeping. Incorporated other applicable CPs through CP 121. +|2016-11-09 |6.0 |Incorporated applicable CPs through CP 128 +|2017-11-09 |7.0 |Incorporated ACM Profile CP 129 to add additional attributes from [PCD-04] to [PCD-06] and [PCD-07] messages, CP 130 to add table of minimally required attributes, CP 131 for [PCD-06] update messages, and to add a mapping table of ISO 60601-1-8 alarm signal states to ACM [PCD-04] attribute values. +|2018-10-23 |8.0 a| +Incorporated into ACM Profile approved CPs + +135 – Change [PCD-05] to use R41 instead of R42 + +136 – Add URI action to paired and unpaired MCR choices + +137 – Add Presentation ID to [PCD-06] + +And to correct incorrect statement regarding ACM Profile not using OBX-7 in [PCD-04] transactions. + +|2019-12-12 |9.0 a| +Infusion Pump Event Communications approved by IHE PCD Technical and Planning Committees as Final Text, so transaction detail from Profile Supplement added to this Technical Framework volume and Appendix M with additional transaction details. + +Incorporated approved Change Proposals + +139 and 140 – PIV Adding detail about supported use cases including bolus from existing infusion (see CP-PCD-141) and (see CP-PCD-142) multistep. + +143 – ACM use optional OBX instance for display text + +144 – PIV – additional values for route of administration in RXR segment + +145 – ACM add timing diagram (informative) + +146 – add Appendix discussing Alarm Fatigue in relation to ACM Profile + +|NOV 2024 |10.0 a| +Incorporated approved Change Proposals + +Since Patient Care Devices (PCD) is now a Program of the IHE Devices (DEV) Domain, the proper prefix for the CP, is CP-DEV- rather than CP-PCD- to avoid confusion the older, more familiar forms may continue in use for a time during the transition. + +PCD-147 - Adding TCI Mode Information (IPEC Profile) + +PCD-148 - Adding information regarding Channel Relay Mode + +PCD-149 - Adding information regarding additional Route values + +PCD-150 –Change PCD-05 field requirements and MSH-16 in PCD-04 + +PCD-151 -ACM HL7 Conformance OBR-3 and OBR-2 + +PCD-152 – MEMDMC Use of MDC_OBS_MEM in OBR-4 in PCD-15 + +PCD-153 –ACM Change PCD-05 PRT-9 from O or C to CE and occurrences to 0..1 + +PCD-154 –ACM AR optional PCD-05 filtering + +PCD-155 –IPEC Identifying infusion pump pillars / slots / racks + +PCD-156 – Corrections to documentation for bolus from existing infusion + +PCD-157 – ACM AM optional PCD-05 retransmission + +PCD-158 –DEC OBX-17 additional MeasureMode Table + +PCD-159 –Correcting information in section E.2.3 Messages + +PCD-161 - ACM alert identifier in OBR segment + +DEV-001 – PCD-03 appendix example corrections + +DEV-002 – PCD-03 OBR-2 Placer Order Number + +DEV-009 – Remove N as a valid value for OBX-11 in IDCO messages + +DEV-010 – Clarify OBX and ED segments + +DEV-011 – DEC OBR-4 allow MDC Codes + +DEV-014 - Update MDCX terms to final MDC terms from 11073-10101b + +Updates to coincide with latest template version + +|=== + +== Conventions + +This document has adopted the following conventions for representing the framework concepts and specifying how the standards upon which the IHE Technical Framework is based shall be applied . + +=== Transaction Modeling and Profiling Conventions + +In order to maintain consistent documentation, modeling methods for IHE transactions and profiling conventions for frequently used standards are maintained in the IHE Technical Frameworks General Introduction, https://profiles.ihe.net/GeneralIntro/ch-E.html[Appendix E - Standards Profiling and Documentation Conventions]. Methods described include the Unified Modeling Language (UML) and standards conventions include DICOM, HL7 v2.x, HL7 Clinical Document Architecture (CDA) Documents, etc. These conventions are critical to understanding this volume and should be reviewed prior to reading this text. + +=== Additional Standards Profiling Conventions + +This section defines profiling conventions for standards which are not described in the https://profiles.ihe.net/GeneralIntro/index.html[IHE Technical Frameworks General Introduction]. + +None. + +=== Use of Coded Entities and Coding Schemes + +Where applicable, coding schemes required by the DICOM^®^, HL7^®^, LOINC^®^, and SNOMED^®^ standards are used in IHE Profiles. In the cases where such resources are not explicitly identified by standards, implementations may utilize any resource (including proprietary or local) provided any licensing/copyright requirements are satisfied. + +IHE does produce and maintain certain terminology. OIDs and URNs have been assigned for specific uses. The IHE process for managing OIDs and URNs is described at http://wiki.ihe.net/index.php/OID_Registration. + +== IHE Devices Transactions + +This section defines each IHE Devices transaction in detail, specifying the standards used and the information transferred. + +=== Communicate PCD Data [PCD-01] + +This section specifies transaction [PCD-01] of the IHE Devices Technical Framework, which is used to transmit patient care device data between systems. Transaction [PCD-01] is used by the Device Observation Reporter and Device Observation Consumer Actors. Note that these actor names are linked to abstract functions rather than to physical devices; a Device Observation Reporter may be implemented in a freestanding system, or it may be implemented in the Patient Care Device itself. + +==== Scope + +This transaction is used to communicate PCD Data from: + +* A Device Observation Reporter (DOR) to a Device Observation Consumer (DOC). + +==== Use Case Roles + +image:extracted-media-tf2/media/image2.png[extracted-media-tf2/media/image2,width=236,height=258] + +Figure 3.1.2-1: Communicate PCD Data + +[width="100%",cols="22%,78%",options="header",] +|=== +|*Actor* |Device Observation Reporter (DOR) +|*Role* |Sends PCD Data to DOC +|*Actor* |Device Observation Consumer (DOC) +|*Role* |Receives PCD Data from DOR +|=== + +==== Referenced Standards + +* HL7 - HL7 Version 2.6 Chapter 7 Observation Reporting +* HL7 – HL7 Version 2.7 Chapter 7 Observation Reporting – PRT Participation Segment with added fields for Unique Device Identification (UDI) +* ISO/IEEE 11073-10201 Domain Information Model +* ISO/IEEE 11073-10101 Nomenclature +* ISO/IEEE 11073-10102-2012 Nomenclature - Annotated ECG defines additional ECG lead identifiers and code offsets > 65 that shall be used as needed by sending systems and shall be understood by receiving systems. + +*Note:* The code offsets 0 to 65 originally defined by ISO/IEEE 11073-10101:2004 Annex A are identical to those defined by ISO/IEEE 11073-10102-2012 and can convey the ECG leads typically reported by a traditional 12-lead resting, stress or Holter ECG in a compatible manner without pre-coordination. + +The IHE Devices Technical Framework uses an information model and a nomenclature from the IEEE 11073. The information model is defined in ISO/IEEE 11073-10201 Health Informatics – Point-of-care medical device communication – Part 10201: Domain Information Model. The nomenclature is defined in ISO/IEEE 11073-10101 Health Informatics – Point -of-care medical device communication – Part 10101: Nomenclature. Familiarity with these standards is necessary for implementers of the Device Observation Reporter and Device Observation Consumer Actors. + +HL7 V2.6 Chapter 7 Observation Reporting defines the general HL7 syntax and coding requirements related to observation reporting, used for PCD data communications in the DEV TF. Familiarity with HL7 Chapter 7 is necessary for implementers of the DEV TF transactions. + +This Technical Framework specifies conventions that are used to represent the information model hierarchy for medical devices embodied in the IEEE 11073 Domain Information Model within the syntactic and semantic conventions of HL7 v. 2.6 + +Definitions of HL7 Data Types used in PCD transactions, with comments on any specializations for PCD, are given in Appendix C, Common Data Types in this volume. + +==== Messages + +The following interaction diagrams illustrate potential implementations. + +===== DOR communicates with DOC + +The [PCD-01] transaction is used to communicate PCD data from: Device Observation Reporter (DOR) to a Device Observation Consumer (DOC). + +image:extracted-media-tf2/media/image3.png[extracted-media-tf2/media/image3,width=458,height=271] + +Figure 3.1.4.1-1: Communicate PCD Data Interaction Diagram + +====== PCD-01 Communicate PCD Data (ORU^R01^ORU_R01) static definition + +The PCD-01 Communicate PCD Data message is used to communicate PCD data + +* From a Device Observation Reporter (DOR) to a Device Observation Consumer (DOC) + +Common HL7 segments (MSH, MSA, ERR, NTE, PID, PV1, OBR, OBX, ORC, PRT) and data types (CWE, CNE, CX, EI, HD, PL, DTM, XPN, XTN) used in IHE PCD transactions are defined in Appendix B, “Common Segment Descriptions”, and Appendix C, "Common Data Types". Note that this message structure differs from the basic HL7 version 2.6 by allowing for the appearance of PRT segments, a segment new in HL7 version 2.7, in certain locations. This is to allow for the need for new participation data needed in transactions added to the ACM Profile in this Technical Framework revision, and for planned future extensions to support FDA Unique Device Identifiers. See Section B.10 for details on the PRT segment. + +The static message is defined with the repeating segment group called "Order Observation". This group can repeat within the message so that a device needs to send only one message with multiple orders. + +[width="100%",cols="19%,39%,12%,10%,20%",options="header",] +|=== +|Segment |Meaning |Usage |Card |HL7 chapter +|MSH |Message Header |R |[1..1] |2 +|[\{SFT}] |Software Segment |X |[0..0] |2 +|[UAC] |User Authentication Credential |O |[0..1] | +|\{ |--- PATIENT_RESULT begin | | | +| [ |--- PATIENT begin | | | +| PID |Patient Identification |R |[1..1] |3 +| [PD1] |Additional Demographics |X |[0..0] |3 +| [\{PRT}] | | | | +| [\{NTE}] |Notes and Comments |X |[0 0] |2 +|  [\{NK1}] |Next of Kin/Associated Parties |O |[0..3] |3 +|  [ |--- VISIT begin | | | +|   PV1 |Patient Visit |R |[1..1] |3 +|   [PV2] |Patient Visit – Additional Info |X |[0..0] |3 +|   [\{PRT}] | | | | +|  ] |--- VISIT end | | | +| ] |--- PATIENT end | | | +| \{ |---ORDER_OBSERVATION begin | | | +|  [ORC] |Order Common |X |[0..0] |4 +|  OBR |Observation Request |R |[1..1] |7 +|  [\{NTE}] |Notes and Comments |O |[0..1] |2 +|  [\{PRT}] | | | | +|  [\{ |--- TIMING_QTY begin | | | +|   TQ1 |Timing/Quantity |R |[1..1] |4 +|   [\{TQ2}] |Timing/Quantity Order Sequence |X |[0..0] |4 +|  }] |--- TIMING_QTY end | | | +|  [CTD] |Contact Data |X |[0..0] |11 +|  [\{ |--- OBSERVATION begin | | | +|   OBX |Observation Result |R |[1..1] |7 +|   [\{PRT}] | | | | +|   [\{NTE}] |Notes and comments |O |[0..1] |2 +|  }] |--- OBSERVATION end | | | +|  [\{FT1}] |Financial Transaction |X |[0..0] |6 +|  [\{CTI}] |Clinical Trial Identification |X |[0..0] |7 +|  [\{ |--- SPECIMEN begin | | | +|   SPM |Specimen |X |[0..0] |7 +|   [\{OBX}] |Observation related to Specimen |X |[0..0] |7 +|  }] |--- SPECIMEN end | | | +| } |--- ORDER_OBSERVATION end | | | +|} |--- PATIENT_RESULT end | | | +|[DSC] |Continuation Pointer |X |[0..0] |2 +|=== + +====== Trigger events + +The ORU^R01^ORU_R01 message is an unsolicited update initiated by the Device Observation Reporter. The ORU^R01 can be sent with or without a preceding order, since it is common in a clinical setting for device data to be reported without a specific order having been transacted in the information system (that is, the reporting is the result of a "standing order" for monitoring in a particular clinical situation). + +While a DOR may be implemented directly on a medical device, it is more often implemented on a gateway or intermediary device as an application which implements the DOR, receiving data from one or more patient care devices using either standards-based or proprietary protocols which are outside the current scope of the IHE DEV TF. + +In general, the DOR sends periodic reports at an interval of between several times per minute (high acuity) and a maximum interval of 24 hours (chronic, home health) with a typical interval of 1 minute. The minimum and maximum intervals are configured at implementation. The DOR may also send aperiodic reports for "event type" information. The DOR shall not do interpolation of data received from the PCD source. + +====== Message Semantics + +Refer to the HL7 standard for the ORU message of HL7 2.6 Chapter 7 and the general message semantics. + +The ORU^OR1^ORU_R01 message structure provides the mechanisms for mapping the hierarchical structure of an IEEE 11073 containment tree to a series of OBX messages each of which is optionally qualified by a note which immediately follows the respective OBX. See the discussion of how the containment is represented using a "dotted notation" in field OBX-4 Observation Sub-ID in Appendix B, Section B.8. + +See Appendix A.1 ISO/IEEE Nomenclature mapping to HL7 OBX-3 for further information on the mapping rules. + +Examples of ORU^R01^ORU_R01 messages implemented in HL7 Encoding Rules (ER7) are provided in Appendix E. + +====== Expected Actions + +The ORU^R01^ORU_R01 message is sent from the DOR to the DOC. Upon receipt, the DOC validates the message and responds with an acknowledgement as defined in Appendix G.1.1 Acknowledgment Modes. + +==== Security Considerations + +During the profile development there were no unusual security or privacy concerns identified. There are no mandatory security controls, but the implementer is encouraged to use the underlying security and privacy profiles from ITI that are appropriate to the transports such as the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk assessment, following ISO 80001, will determine the actual security and safety controls employed. + +=== [PCD-02] Reserved + +=== Communicate Infusion Order [PCD-03] + +This section specifies transaction [PCD-03] of the IHE Devices Technical Framework. Transaction [PCD-03] is used by the Infusion Order Programmer and Infusion Order Consumer. + +Since the IOC is typically a gateway rather than an infusion pump, all of the information specified in the Communicate Infusion Order [PCD-03] transaction is not necessarily provided to or used to program the device. + +Note: See related detail on infusion pump device models and data models in the Device Specialization – Infusion Pump PCD profiles for large volume, syringe, and patient controlled analgesia (PCA) pumps. + +==== Scope + +This transaction is used to communicate Infusion Order parameters from an Infusion Order Programmer (IOP) to an Infusion Order Consumer (IOC). + +==== Use Case Roles + +[width="100%",cols="17%,83%",options="header",] +|=== +|*Actor* |Infusion Order Programmer +|*Role* |Sends Infusion Order parameters to IOC +|*Actor* |Infusion Order Consumer +|*Role* |Receives Infusion Order parameters from IOP and in turn programs the pump +|=== + +==== Referenced Standards + +* HL7 - HL7 Version 2.6 Ch4 Order Entry +* ISO/IEEE 11073-10101 Nomenclature +* ISO/IEEE 11073-10201 Domain Information Model + +==== Messages + +The following interaction diagram illustrates the implementation. + +image:extracted-media-tf2/media/image4.png[extracted-media-tf2/media/image4,width=280,height=231] + +Figure 3.3.4-1: Communicate Infusion Order + +===== PCD-03 Communicate Infusion Order (RGV^O15^RGV_O15) static definition + +The PCD-03 Communicate Infusion Order message is used to communicate infusion data from an Infusion Order Programmer (IOP) to an Infusion Order Consumer (IOC). + +Since the IOC is typically a gateway rather than an infusion pump, all of the information specified in the Communicate Infusion Order [PCD-03] transaction is not necessarily provided to or used to program the device. + +All HL7 segments used in the [PCD-03] transaction are defined within this document. + +===== RGV^O15^RGV_O15 Pharmacy/Treatment Give Message + +Table 3.3.4.2-1: RGV^O15^RGV_O15 Pharmacy/Treatment Give Message + +[width="100%",cols="20%,31%,16%,16%,17%",options="header",] +|=== +|Segment |Meaning |Usage |Card |HL7 Chapter +|MSH |Message Header |R |[1..1] |2 +|[\{ SFT }] |Software |X | |2 +|[\{ NTE }] |Notes and Comments (for Header) |X | |2 +|[ |--- PATIENT begin | | | +|PID |Patient Identification |R |[1..1] |3 +|[\{ NTE }] |Notes and Comments (for PID) |X | |2 +|[\{ AL1 }] |Allergy Information |X | |2 +|[ |--- PATIENT_VISIT begin | | | +|PV1 |Patient Visit |O |[0..1] |3 +|[ PV2 ] |Patient Visit – Additional Info |X | |3 +|] |--- PATIENT_VISIT end | | | +|] |--- PATIENT end | | | +|\{ |--- ORDER begin | | | +|ORC |Common Order |R |[1..1] |4 +|[\{ |--- TIMING begin | | | +|TQ1 |Timing/Quantity |X | |4 +|[\{ TQ2 }] |Timing/Quantity Order Sequence |X | |4 +|}] |--- TIMING end | | | +|[ |--- ORDER_DETAIL begin | | | +|RXO |Pharmacy /Treatment Order |X | |4 +|[ |--- ORDER_DETAIL_SUPPLEMENT begin | | | +|\{ NTE } |Notes and Comments (for RXO) |X | |2 +|\{ RXR } |Pharmacy/Treatment Route |X | |4 +|[\{ |--- COMPONENTS begin | | | +|RXC |Pharmacy/Treatment Component |X | |4 +|[\{ NTE }] |Notes and Comments (for each RXC) |X | |2 +|}] |--- COMPONENTS end | | | +|] |--- ORDER_DETAIL_SUPPLEMENT end | | | +|] |--- ORDER_DETAIL end | | | +|[ |--- ENCODING begin | | | +|RXE |Pharmacy/Treatment Encoded Order |X | |4 +|\{ |--- TIMING_ENCODED begin | | | +|TQ1 |Timing/Quantity |X | |4 +|[\{ TQ2 }] |Timing/Quantity Order Sequence |X | |4 +|} |--- TIMING_ENCODED end | | | +|\{ RXR } |Pharmacy/Treatment Route |X | |4 +|[\{ RXC }] |Pharmacy/Treatment Component |X | |4 +|] |--- ENCODING end | | | +|\{ |--- GIVE begin | | | +|RXG |Pharmacy/Treatment Give |R |[1..1] |4 +|\{ |--- TIMING_GIVE begin | | | +|TQ1 |Timing/Quantity |O |[0..1] |4 +|[\{ TQ2 }] |Timing/Quantity Order Sequence |X | |4 +|} |--- TIMING_GIVE end | | | +|\{ RXR } |Pharmacy/Treatment Route |R |[1..1] |4 +|[\{ RXC }] |Pharmacy/Treatment Component |X | |4 +|\{ |--- OBSERVATION begin | | | +|[ OBX ] |Observation/Results |R |[1..n] |7 +|[\{ NTE }] |Notes and Comments (for OBX) |X | |2 +|} |--- OBSERVATION end | | | +|} |--- GIVE end | | | +|} |--- ORDER end | | | +|=== + +===== Trigger Events + +The RGV^O15^RGV_O15 message is generated by the Infusion Order Programmer when the caregiver initiates an action to administer a medication using an IV pump. + +===== Message Semantics + +Refer to the HL7 standard for the RGV message in HL7 2.6 Chapter 4 for the general message semantics. + +====== MSH – Message Header Segment + +This segment defines the intent, source, destination, and some specifics of the syntax of a message. See HL7 v2.6: chapter 2 Message control. For MSH usage in IHE Devices Technical Framework profiles, refer to Appendix B.1 of this volume. MSH-15 and MSH-16 fields have special considerations in PCD 03: + +*MSH-15 Accept Acknowledgement Type (ID), required:* + +____ +This is required for all messages. The Accept Acknowledgement Type field shall be valued with “AL” (always) by the IOP in a RGV^O15 message and by the IOC in a RRG^O16 message. + +The receiving application must transmit the accept acknowledgement on the same network connection as the initiating RGV^ O15 or RRG^O16 message +____ + +*MSH-16 Application Acknowledgement Type (ID), required:* + +____ +This is required for all messages. The application acknowledgement field informs the receiver whether the sender can process application acknowledgements and under what conditions to send the additional acknowledgement. For RGV^O15 messages, the value shall be “AL”, and for RRG^O16 the value shall be “NE”. The receiving system must send (or not send) application acknowledgements as specified by this field. + +When the sending an application acknowledgement, the receiving application must initiate a new network connection for the transaction. Here is an example of an IOP to IOC transaction: +____ + +[arabic] +. image:extracted-media-tf2/media/image5.emf[Description: visio02,width=441,height=274]The IOP sends a RGV^O15 message on the IOC’s port 3000 with MSH-15=”AL” and MSH-16=”AL”. +. The IOC receives the message on port 3000 and transmits an ACK^O15 to the IOP on the same network connection with MSH-15=’NE’ and MSH-16=’NE’, since the sender does not need to reply to an Accept Acknowledgement . + +image:extracted-media-tf2/media/image6.emf[Description: EnhAck02,width=457,height=284] + +[arabic, start=3] +. After completing application processing, the IOC transmits a RRG^O16 on a different network connection (e.g., the IOP’s port 3001) with MSH-15=”AL” and MSH-16=”NE”. +. The IOP receives the message on port 3001 and sends an ACK^O16 to the IOC on the same network connection with MSH-15=’NE’ and MSH-16=’NE’, since the sender does not need to reply to an Accept Acknowledgement. + +The table below identifies the possible values for MSH-16: + +Table 3.3.4.4.1-1: Possible Values for MSH-16 in PCD-03 RGV^O15 and RRG^O16 Messages + +[width="100%",cols="20%,29%,51%",options="header",] +|=== +|Value |Description |Comments +|AL |Always |The sender expects to receive an application acknowledgement in addition to the accept acknowledgement. This value shall be used in RGV^O15 messages. +|NE |Never |The sender does not expect to receive an application acknowledgement. This value shall be used in RRG^O16 messages. +|=== + +====== PID - Patient Identification Segment + +The PID segment is used by all applications as the primary means of communicating patient identification information. This segment contains permanent patient identifying and demographic information that, for the most part, is not likely to change frequently. See HL7 v2.6: chapter 3 (3.4.2). For PID usage in IHE Devices Technical Framework profiles, refer to Appendix B.5 of this volume. + +====== PV1 Patient Visit Segment + +The PV1 segment is used by Registration/Patient Administration applications to communicate information on an account or visit-specific basis. See Appendix B.6 for details. + +====== ORC - Common Order Segment + +The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). See Appendix B.9 for details of usage in IHE PCD profiles. + +====== RXG - Pharmacy/Treatment Give Segment + +Table 3.3.4.4.5-1: HL7 Attribute Table – RXG – Pharmacy/Treatment Give + +[width="100%",cols="11%,9%,8%,10%,12%,10%,10%,30%",options="header",] +|=== +|SEQ |LEN |DT |Usage |Card. |TBL# |ITEM # |ELEMENT NAME +|1 |4 |NM |R |[1..1] | |00342 |Give Sub-ID Counter +|2 |4 |NM |RE |[0..1] | |00334 |Dispense Sub-ID Counter +|3 |705 |TQ |X |[0..0] | |00221 |Quantity/Timing +|4 |705 |CWE |R |[1..1] |0292 |00317 |Give Code +|5 |20 |NM |CE |[0..1] | |00318 |Give Amount - Minimum +|6 |20 |NM |RE |[0..1] | |00319 |Give Amount - Maximum +|7 |705 |CWE |CE |[0..1] | |00320 |Give Units +|8 |705 |CWE |RE |[0..1] | |00321 |Give Dosage Form +|9 |705 |CWE |RE |[0..*] | |00351 |Administration Notes +|10 |1 |ID |RE |[0..1] |0167 |00322 |Substitution Status +|11 |200 |LA2 |RE |[0..1] | |01303 |Dispense-To Location +|12 |1 |ID |RE |[0..1] |0136 |00307 |Needs Human Review +|13 |705 |CWE |RE |[0..*] | |00343 |Pharmacy/Treatment Supplier's Special Administration Instructions +|14 |20 |ST |RE |[0..1] | |00331 |Give Per (Time Unit) +|15 |6 |ST |CE |[0..1] | |00332 |Give Rate Amount +|16 |705 |CWE |CE |[0..1] | |00333 |Give Rate Units +|17 |20 |NM |RE |[0..1] | |01126 |Give Strength +|18 |705 |CWE |RE |[0..1] | |01127 |Give Strength Units +|19 |20 |ST |RE |[0..*] | |01129 |Substance Lot Number +|20 |24 |DTM |RE |[0..*] | |01130 |Substance Expiration Date +|21 |705 |CWE |RE |[0..*] |0227 |01131 |Substance Manufacturer Name +|22 |705 |CWE |RE |[0..*] | |01123 |Indication +|23 |5 |NM |RE |[0..1] | |01692 |Give Drug Strength Volume +|24 |705 |CWE |RE |[0..1] | |01693 |Give Drug Strength Volume Units +|25 |60 |CWE |RE |[0..1] | |01694 |Give Barcode Identifier +|26 |1 |ID |RE |[0..1] |0480 |01695 |Pharmacy Order Type +|27 |705 |CWE |X |[0..0] | |01688 |Dispense to Pharmacy +|28 |106 |XAD |X |[0..0] | |01689 |Dispense to Pharmacy Address +|29 |80 |PL |X |[0..0] | |01683 |Deliver-to Patient Location +|30 |250 |XAD |X |[0..0] | |01684 |Deliver-to Address +|=== + +The following describes the IHE PCD usage of those fields which have a usage other than X in the above table. + +RXG-1 Give Sub-ID Counter + +When used for a multistep infusion this field contains the step number (1..n). + +For other uses see HL7 V2.6 Section 4.14.6.1 for details. The DEV TF does not further constrain this field. + +RXG-2 Dispense Sub-ID Counter + +See HL7 V2.6 Section 4.14.6.2 for details. The DEV TF does not further constrain this field. + +RXG-4 Give Code + +Components: ^ ^ ^ ^ ^ ^ ^ ^ + +Definition: This field is the identifier of the primary additive or principal ingredient of the IV medication to be administered to the patient. + +Subfields CWE-1 "Identifier" and CWE-2 "Text" are required for each identifier. Typically, "Identifier" would be populated with a value such as an NDC or another value known to both the Infusion Order Programmer and the Infusion Order Consumer. "Text" would typically be populated with the generic name of the medication. The information provided in either Identifier or Text is used to match the ordered medication to the onboard drug library. + +RXG-5 Give Amount – Minimum + +Definition: This field contains the volume of fluid to be administered (VTBI). This volume is the actual fluid volume that the clinician intends to administer (not necessarily the volume contained in the bag, bottle, syringe, or other fluid container). + +Required for LVP when TQ1 segment is not present. Optional for PCA and Syringe. + +Must be empty when ORC-1 = “XO”. + +When this field is empty, there should be no implication made about the volume of fluid to be administered. + +RXG-6 Give Amount - Maximum + +See HL7 V2.6 Section 4.14.6.6 for details. The DEV TF does not further constrain this field. + +RXG-7 Give Units + +Components: ^ ^ ^ ^ ^ ^ ^ ^ + +Definition: This field contains the coded units for the Give Amount. The preferred format is an MDC value; UCUM values are also acceptable. + +Required for LVP when TQ1 segment is not present; Optional for PCA and Syringe. + +Must be empty when ORC-1 = “XO”. + +The DEV TF requires that the first three components of RXG-7 contain one of the following sets of values: + +* 263762^MDC_DIM_MILLI_L^MDC +* mL^mL^UCUM + +RXG-8 Give Dosage Form + +See HL7 V2.6 Section 4.14.6.8 for details. The DEV TF does not further constrain this field. + +RXG-9 Administration Notes + +See HL7 V2.6 Section 4.14.6.9 for details. The DEV TF does not further constrain this field. + +RXG-10 Substitution Status + +See HL7 V2.6 Section 4.14.6.10 for details. The DEV TF does not further constrain this field. + +RXG-11 Dispense-to Location + +See HL7 V2.6 Section 4.14.6.11 for details. The DEV TF does not further constrain this field. + +RXG-12 Needs Human Review + +See HL7 V2.6 Section 4.14.6.12 for details. The DEV TF does not further constrain this field. + +RXG-13 Pharmacy/Treatment Supplier's Special Administration Instructions + +See HL7 V2.6 Section 4.14.6.13 for details. The DEV TF does not further constrain this field. + +RXG-14 Give Per (Time Unit) + +See HL7 V2.6 Section 4.14.6.14 for details. The DEV TF does not further constrain this field. + +RXG-15 Give Rate Amount + +Definition: This field contains the numeric portion of the rate, dose rate, or dose amount to be administered. + +If the infusion order specifies a rate, such as normal saline at 75 mL/hr, then this field contains the rate value amount (e.g., "75"). + +If the infusion order specifies a dose rate, such as dopamine at 5 mcg/kg/min, this field contains the dose rate value amount (e.g., “5"). + +If the infusion order specifies a dose amount, such as 2 g, this field contains the dose value amount (e.g., “2”). + +Required for LVP and Syringe; Optional for PCA. If present for PCA, contains the basal or continuous rate value. + +RXG-16 Give Rate Units + +Components: ^ ^ ^ ^ ^ ^ ^ ^ + +Definition: This field contains the coded version of the units portion of the rate, dose rate, or dose to be administered. + +If the infusion order specifies a rate, such as normal saline to infuse at 75 mL/hr, this field represents the rate units (e.g., "mL/hr"). + +If the infusion order specifies a dose rate, such as dopamine to infuse at 5 mcg/kg/min, this field represents the dose rate units (e.g., "mcg/kg/min"). + +If the infusion order specifies a dose, such as ceftriaxone 2 g, this field represents the dose units (e.g., “g”). + +When a dose is specified the TQ1 segment must be present to indicate the time period that the dose is to be infused over. + +The preferred format is an MDC value; UCUM values are also acceptable. + +Required for LVP and Syringe; Optional for PCA. If present for PCA, contains the basal or continuous rate units value. + +Examples: + +265266^MDC_DIM_MILLI_L_PER_HR^MDC + +265619^MDC_DIM_MICRO_G_PER_KG_PER_MIN^MDC + +263872^MDC_DIM_X_G^MDC + +ml/h^ml/h^UCUM + +ug/kg/min^ug/kg/min^UCUM + +g^g^UCUM + +RXG-17 Give Strength + +Definition: This field contains the quantity of the main ingredient in the infusion, e.g., for dopamine 800 mg in 250 mL D5W, the field would contain the value "800". + +RXG-18 Give Strength Units + +Components: ^ ^ ^ ^ ^ ^ ^ ^ + +This field contains the coded version of the units portion of the main ingredient in the infusion; e.g., for dopamine 800 mg in 250 mL D5W, the field would represent ‘mg". The preferred format is an MDC value; UCUM values are also acceptable: + +Examples: + +263890^MDC_DIM_MILLI_G^MDC + +mg^mg^UCUM + +RXG-19 Substance Lot Number + +See HL7 V2.6 Section 4.14.6.19 for details. The DEV TF does not further constrain this field. + +RXG-20 Substance Expiration Date + +See HL7 V2.6 Section 4.14.6.20 for details. The DEV TF does not further constrain this field. + +RXG-21 Substance Manufacturer Name + +See HL7 V2.6 Section 4.14.6.21 for details. The DEV TF does not further constrain this field. + +RXG-22 Indication + +See HL7 V2.6 Section 4.14.6.22 for details. The DEV TF does not further constrain this field. + +RXG-23 Give Drug Strength Volume + +Definition: This field contains the quantity of the diluent or base fluid ingredient(s) in the infusion, e.g., for dopamine 800 mg in 250 mL D5W, the field would contain the value "250". + +RXG-24 Give Drug Strength Volume Units + +Components: ^ ^ ^ ^ ^ ^ ^ ^ + +Definition: This field contains the coded units for the Give Drug Strength Volume. The preferred format is an MDC value; UCUM values are also acceptable. + +The DEV TF requires that the first three components of RXG-24 contain one of the following sets of values: + +* 263762^MDC_DIM_MILLI_L^MDC +* mL^mL^UCUM + +RXG-25 Give Barcode Identifier + +See HL7 V2.6 Section 4.14.6.25 for details. The DEV TF does not further constrain this field. + +RXG-26 Pharmacy Order Type + +See HL7 V2.6 Section 4.14.6.26 for details. The DEV TF does not further constrain this field. + +RXG-27 to 30 + +These fields are not supported by the DEV TF. + +====== Usage notes for RXG 17, 18, 23, and 24 + +These fields are used by the pump or gateway to determine the concentration of the main ingredient in the infusion. Concentration is defined as: + +{empty}[Medication amount][units] / [Diluent amount][units] + +Example: 800 mg / 250 mL + +The pump’s onboard drug library may require this information in order to apply dosing limits to ensure the safe administration of a particular infusion. The "rules" contained in the drug library may be different for different concentrations of the same drug. For example, there may be two different rules for the medication "dopamine": one specific for dopamine 800 mg in 250 mL, and another for any other concentration. + +The BCMA system cannot know when the information is required since the drug library definition is internal to the pump system. BCMA systems may extract the information needed from the underlying order, from their formulary, or both. Basically, if the BCMA is able to determine these values, they should be supplied in the [PCD-03] transaction. + +An analogy to a pharmacy order for an IV fluid containing multiple components (RXC segments) may be helpful in determining how to populate these values. In [PCD-03], RXG-17 and 18 (Give Strength/Units) are analogous to the Component Strength and Units (RXC-5 and 6) for the additive component (i.e., RXC-1 = "A"). Similarly, RXG-23 and 24 (Give Drug Strength Volume/Units) are similar to Component Drug Strength Volume and Units (RXC-8 and 9) for the base component (RXC-1 = "B"). + +Example: + +Ampicillin 1 g/Sodium chloride 50 mL + +RXC segments for Ampicillin (pharmacy order message): + +[width="100%",cols="25%,15%,15%,15%,15%,15%",options="header",] +|=== +|Component |RXC-1 |RXC-5 |RXC-6 |RXC-8 |RXC-9 +|Ampicillin |A |1 |G | | +|Sodium chloride |B | | |50 |ML +|=== + +RXG segment population for Ampicillin: + +[width="100%",cols="14%,32%,14%,40%",options="header",] +|=== +|RXG-17 |RXG-18 |RXG-23 |RXG-24 +|1 |263872^MDC_DIM_X_G^MDC |50 |263762^MDC_DIM_MILLI_L^MDC +|=== + +*Premixed medication orders* + +Certain marketed medication products are "premixed", containing both the additive and the base mixed together and sold as a single item. + +Examples: + +Dopamine 800 mg / Dextrose 5% 250 mL + +Cefazolin 1 g / Dextrose 5% 50 mL + +RXG segment population for Dopamine: + +[width="100%",cols="14%,36%,13%,37%",options="header",] +|=== +|RXG-17 |RXG-18 |RXG-23 |RXG-24 +|800 |263890^MDC_DIM_MILLI_G^MDC |250 |263762^MDC_DIM_MILLI_L^MDC +|=== + +*Fluid orders* + +"Plain" IV fluids do not contain an additive. The BCMA is not required to populate RXG-17, 18, 23, and 24 for these orders. + +Examples: + +Dextrose 5% 1000 mL + +Sodium Chloride 0.9% 250 mL + +*Orders with multiple additives* + +Some infusion orders may contain multiple additives, for example, total parenteral nutrition (TPN) solutions are made up of one or more base solutions and as many as 10 or 12 additives. The BCMA is not required to populate RXG-17, 18, 23, and 24 for these orders. + +====== TQ1 Timing Quantity Segment + +This segment is an optional segment which allows the IOP to specify the duration of the infusion order. Along with the ordered dose (RXG.18) the infuser can then calculate the rate at which the infusion should be run. Not all IOCs will be able to support duration-based infusions, and even vendors that do support will have limits on the types of infusions which support duration. See each vendor’s implementation guide for further details. + +Table 3.3.4.4.7-1: TQ1 Timing Quantity Segment Attributes + +[width="100%",cols="14%,8%,7%,10%,10%,9%,11%,31%",options="header",] +|=== +|SEQ |LEN |DT |Usage |Card. |TBL# |ITEM # |ELEMENT NAME +|1 |4 |SI |O |[0..1] | |01627 |Set ID - TQ1 +|2 |20 |CQ |X |[0..0] | |01628 |Quantity +|3 |540 |RPT |X |[0..0] |0335 |01629 |Repeat Pattern +|4 |20 |TM |X |[0..0] | |01630 |Explicit Time +|5 |20 |CQ |X |[0..0] | |01631 |Relative Time and Units +|6 |20 |CQ |X |[0..0] | |01632 |Service Duration +|7 |26 |TS |X |[0..0] | |01633 |Start date/time +|8 |26 |TS |X |[0..0] | |01634 |End date/time +|9 |705 |CWE |X |[0..0] |0485 |01635 |Priority +|10 |250 |TX |X |[0..0] | |01636 |Condition text +|11 |250 |TX |X |[0..0] | |01637 |Text instruction +|12 |10 |ID |X |[0..0] |0427 |01638 |Conjunction +|13 |20 |CQ |R |[1..3] | |01639 |Occurrence duration +|14 |10 |NM |X |[0..1] | |01640 |Total occurrence’s +|=== + +TQ1-1 Set ID + +See HL7 v2.6 Section 4.5.4.1 for details. The DEV TF does not further constrain this field. + +TQ1-2 Quantity + +See HL7 v2.6 Section 4.5.4.2 for details. The DEV TF does not further constrain this field. + +TQ1-3 Repeat Pattern + +See HL7 v2.6 Section 4.5.4.3 for details. The DEV TF does not further constrain this field. + +TQ1-4 Explicit Time + +See HL7 v2.6 Section 4.5.4.4 for details. The DEV TF does not further constrain this field. + +TQ1-5 Relative Time and Units + +See HL7 v2.6 Section 4.5.4.5 for details. The DEV TF does not further constrain this field. + +TQ1-6 Service Duration + +See HL7 v2.6 Section 4.5.4.6 for details. The DEV TF does not further constrain this field. + +TQ1-7 Start date/time + +See HL7 v2.6 Section 4.5.4.7 for details. The DEV TF does not further constrain this field. + +TQ1-8 End date/time + +See HL7 v2.6 Section 4.5.4.8 for details. The DEV TF does not further constrain this field. + +TQ1-9 Priority + +See HL7 v2.6 Section 4.5.4.9 for details. The DEV TF does not further constrain this field. + +TQ1-10 Condition text + +See HL7 v2.6 Section 4.5.4.10 for details. The DEV TF does not further constrain this field. + +TQ1-11 Text instruction + +See HL7 v2.6 Section 4.5.4.11 for details. The DEV TF does not further constrain this field. + +TQ1-12 Conjunction + +See HL7 v2.6 Section 4.5.4.12 for details. The DEV TF does not further constrain this field. + +TQ1-13 Occurrence duration + +Components: ^ Subcomponents for Units (CE): & & & & & + +This field specifies the duration of the infusion. Along with the dose or the volume to be administered the rate can be calculated by the infuser. + +The only acceptable time values for this field are seconds, minutes, and hours. To specify multiple components of time, this field can be repeated two additional times. + +[width="100%",cols="36%,64%",options="header",] +|=== +|Unit of Time |MDC Code +|Hour |264384&MDC_DIM_HR&MDC +|Minute |264352&MDC_DIM_MIN&MDC +|Second |264320&MDC_DIM_X_SEC&MDC +|=== + +Examples: + +90 Seconds: + +90^264320&MDC_DIM_X_SEC&MDC + +2 Hours 45 Minutes: + +2^264384&MDC_DIM_HR&MDC~45^264352&MDC_DIM_MIN&MDC + +TQ1-14 Total occurrences + +See HL7 v2.6 Section 4.5.4.14 for details. The DEV TF does not further constrain this field. + +====== RXR - Pharmacy/Treatment Route Segment + +The Pharmacy/Treatment Route segment contains the alternative combination of route, site, administration device, and administration method that are prescribed. + +Table 3.3.4.4.8-1: HL7 Attribute Table – RXR – Pharmacy/Treatment Route + +[width="100%",cols="12%,9%,8%,10%,9%,11%,11%,30%",options="header",] +|=== +|SEQ |LEN |DT |Usage |Card. |TBL# |ITEM # |ELEMENT NAME +|1 |705 |CWE |R |[1..1] |0162 |00309 |Route +|2 |705 |CWE |RE |[0..1] |0550 |00310 |Administration Site +|3 |705 |CWE |RE |[0..1] |0164 |00311 |Administration Device +|4 |705 |CWE |CE |[0..1] |0165 |00312 |Administration Method +|5 |705 |CWE |RE |[0..1] | |01315 |Routing Instruction +|6 |705 |CWE |RE |[0..1] |0495 |01670 |Administration Site Modifier +|=== + +The following describes the IHE PCD usage of the fields in the above table. + +RXR-1 Route + +Components: ^ ^ ^ ^ ^ ^ ^ ^ + +Definition: This field is the route of administration. The DEV TF requires that this field be valued as one of the following: ^IV^HL70162 for Intravenous, ^EP^HL70162 for Epidural, ^SC^HL70162 for Subcutaneous, ^NG^HL70162 for Nasogastric, ^GTT^HL70162 for Gastrostomy Tube or ^IT^HL70162 for Intrathecal. + +*RXR-2 Administration Site* + +See HL7 V2.6 Section 4.14.2.2 for details. The DEV TF does not further constrain this field. + +RXR-3 Administration Device + +Components: ^ ^ ^ ^ ^ ^ ^ ^ + +Definition: This field contains the type of pump used to administer the drug, if known by the BCMA system. The DEV TF requires that this field be valued as ^IVP^HL70164 for LVP pumps, ^PCA^HL70164 for PCA pumps, or ^SYR^HL70164 for Syringe pumps. + +The following entry should be added to HL7 user-defined table #0164: + +[width="100%",cols="42%,58%",options="header",] +|=== +|Value |Description +|SYR |Syringe Pump +|=== + +RXR-4 Administration Method + +Components: ^ ^ ^ ^ ^ ^ ^ ^ + +Definition: This field identifies whether the infusion is to be administered as a primary infusion or as an IV piggyback or secondary infusion. The TF requires that this field be valued as ^IV^HL70165 for a primary infusion or ^IVPB^HL70165 for an IV piggyback or secondary infusion. This field is optional for PCA. + +The following entry should be added to HL7 user-defined table #0165: + +[width="100%",cols="42%,58%",options="header",] +|=== +|Value |Description +|IV |IV Primary +|=== + +RXR-5 Routing Instruction + +See HL7 V2.6 Section 4.14.2.5 for details. The DEV TF does not further constrain this field. + +RXR-6 Administration Site Modifier + +See HL7 V2.6 Section 4.14.2.6 for details. The DEV TF does not further constrain this field. + +====== OBX - Observation/Result segment + +Refer to HL7 v2.6: Section 7.4.2x + +The HL7 OBX segment is used to transmit a single observation or observation fragment. In the + +Point-of-Care Infusion Verification Profile the usage is limited to providing: + +[arabic] +. pump ID + +[arabic, start=5] +. patient parameters such as height, weight, or body surface area (BSA) +. infusion order step type +. other parameters used to program the pump. + +Note that the definition of the OBX segment in this profile is constrained from the definition used in the PCD Observation/Result Message to reflect this limited usage. The broader definition can be found in OBX - Observation/Result segment, Appendix Section B-8. + +One OBX segment containing the pump ID must always be present. Additional OBX segments containing patient parameters, infusion order step type, or pump programming parameters may optionally follow. + +Table 3.3.4.4.9-1: OBX segment + +[width="100%",cols="11%,11%,11%,11%,15%,9%,32%",options="header",] +|=== +|SEQ |LEN |DT |Usage |Card. |TBL# |Element name +|1 |4 |SI |R |[1..1] | |Set ID – OBX +|2 |3 |ID |CE |[0..1] |0125 |Value Type +|3 |705 |CWE |R |[1..1] | |Observation Identifier +|4 |20 |ST |RE |[0..1] | |Observation Sub-ID +|5 |99999 |Varies |CE |[0..1] | |Observation Value +|6 |705 |CWE |CE |[0..1] | |Units +|7 |60 |ST |RE |[0..1] | |References Range +|8 |5 |IS |RE |[0..1] |0078 |Abnormal Flags +|9 |5 |NM |X |[0..0] | |Probability +|10 |2 |ID |RE |[0..1] |0080 |Nature of Abnormal Test +|11 |1 |ID |RE |[0..1] |0085 |Observation Result Status +|12 |24 |DTM |X |[0..0] | |Effective Date of Reference Range +|13 |20 |ST |X |[0..0] | |User Defined Access Checks +|14 |24 |DTM |RE |[0..1] | |Date/Time of the Observation +|15 |705 |CWE |RE |[0..1] | |Producer's ID +|16 |3220 |XCN |RE |[0..1] | |Responsible Observer +|17 |705 |CWE |RE |[0..1] | |Observation Method +|18 |427 |EI |CE |[0..1] | |Equipment Instance Identifier +|19 |24 |DTM |RE |[0..1] | |Date/Time of the Analysis +|20 |705 |CWE |RE |[0..*] |0163 |Observation Site +|=== + +The following describes the IHE PCD PIV Profile’s usage of those fields which have a usage other than X in the above table. + +OBX-1 Set ID + +This field contains the sequence number of the OBX in this message, i.e., 1st OBX Set ID = 1, 2nd OBX set ID = 2, etc., regardless of whether the OBX refers to a device or a metric value. + +OBX-2 Value Type + +The PCD PIV Profile constrains this field as follows: + +If OBX-3 refers to a pump ID this field must be empty. + +If OBX-3 refers to a patient parameter that conveys a numeric quantity (e.g., patient weight), this value is restricted to NM. + +If OBX-3 refers to an infusion order step type this field must be “ST”. + +If OBX-3 refers to a pump programming parameter, this value should identify the data type of the value in OBX-5 Observation Value. + +OBX-3 Observation Identifier + +The PCD PIV Profile constrains the value of this field to one of the following: + +Pump ID + +69986^MDC_DEV_PUMP_INFUS_VMD^MDC + +Patient parameter + +68063^MDC_ATTR_PT_WEIGHT^MDC + +68060^MDC_ATTR_PT_HEIGHT^MDC + +188744^MDC_AREA_BODY_SURF_ACTUAL^MDC + +Pump programming parameter + +157985^MDC_DOSE_PCA_LIMIT^MDC + +157986^MDC_VOL_PCA_DOSE_LIMIT^MDC + +157987^MDC_TIME_PD_PCA_DOSE_LIMIT^MDC + +157988^MDC_RATE_PCA_MAX_DOSES_PER_HOUR^MDC + +157989^MDC_TIME_PCA_LOCKOUT^MDC + +157994^MDC_VOL_FLUID_CONTAINER_START^MDC + +158017^MDC_DOSE_PCA_PATIENT^MDC + +158019^MDC_DOSE_CLINICIAN^MDC + +158018^MDC_DOSE_LOADING^MDC + +158037^MDC_INFUS_ORDER_STEP_TYPE^MDC + +157998^MDC_TIME_PD_DOSE_START_INTERVAL^MDC + +158023^MDC_DOSE_INTERMITTENT^MDC + +158025^MDC_TIME_PROG_NEXT_DOSE^MDC + +OBX-4 Observation Sub-ID + +The PC PIV Profile does not further constrain this field. + +OBX-5 Observation Value + +If OBX-3 refers to a pump ID, this field must be empty. + +If OBX-3 refers to a patient parameter, this field contains the parameter value. + +If OBX-3 refers to an infusion order step type, the field contains the enumerated value + +If OBX-3 refers to a pump programming parameter, this field contains the parameter value. + +OBX-6 Units + +The PCD PIV Profile constrains the value of this field based on the value in OBX-3. + +If OBX-3 refers to a pump ID, this field must be empty. + +If OBX-3 refers to a patient parameter, this field contains the coded units for the parameter. The preferred format is an MDC value; UCUM values are also acceptable. + +When OBX-3 refers to weight, the first three components of OBX-6 must contain one of the following sets of values: + +263872^MDC_DIM_X_G^MDC + +263875^MDC_DIM_KILO_G^MDC + +g^g^UCUM + +kg^kg^UCUM + +When OBX-3 refers to height, the first three components of OBX-6 must contain one of the following sets of values: + +263441^MDC_DIM_CENTI_M^MDC + +cm^cm^UCUM + +When OBX-3 refers to BSA, the first three components of OBX-6 must contain one of the following sets of values: + +263616^ MDC_DIM_SQ_X_M^MDC + +m2^m2^UCUM + +If OBX-3 refers to an infusion order step type, this field must be empty. + +If OBX-3 refers to a pump programming parameter, this field contains the units for the value in OBX-5 Observation Value. + +OBX-7 References Range: + +The PCD PIV Profile does not further constrain this field. + +OBX-8 Abnormal Flags + +The PCD PIV Profile does not further constrain this field. + +OBX-10 Nature of Abnormal Test + +The PCD PIV Profile does not further constrain this field. + +OBX-11 Observation Result Status + +The PCD PIV Profile does not further constrain this field. + +OBX-14 Date/Time of the Observation + +The PCD PIV Profile does not further constrain this field. + +OBX-15 Producer’s ID + +The PCD PIV Profile does not further constrain this field. + +OBX-16 Responsible Observer (XCN) + +The PCD PIV Profile does not further constrain this field. + +OBX-17 Observation Method + +The PCD PIV Profile does not further constrain this field. + +OBX-18 Equipment Instance Identifier + +See Appendix B.8 for description of usage of OBX-18. + +If OBX-3 refers to a pump ID, the following applies. + +* For backward compatibility, when used to contain a pump ID, the OBX-18 convention used in previous Trial Implementation versions of the Point-of-Care Infusion Verification Supplement may be used by agreement between sending and receiving systems, but this usage is deprecated and should not be used in new systems. The former language is reproduced here: "If OBX-3 refers to the pump ID, the ID is placed in the ‘Universal ID’ component (EI-3), and the device or manufacturer name is placed in the ‘Universal ID Type’ component (EI-4). The pump ID is a unique alphanumeric identifier and may optionally include the pump channel. The format of the identifier is vendor specific. A typical value could be a serial number for a single-channel pump, or a serial number followed by the channel number or letter for a multi-channel pump. Note that this specification differs from the usage of OBX-18 in IHE PCD DEC Profile." +* New applications should conform to the general specification for OBX-18 (Appendix B.8). The pump ID (vendor-specific format, which may optionally include the pump channel as before) should be placed in EI-1, and EI-3 and EI-4 should identify the manufacturer of the pump according to an accepted Universal ID system. +* If OBX-3 refers to a patient parameter this field must be empty. + +If OBX-3 refers to a pump programming parameter this field must be empty. + +OBX-19 Date/Time of the Analysis + +The PCD PIV Profile does not further constrain this field. + +OBX-20 Observation Site + +The PCD PIV Profile does not further constrain this field. + +OBX-21 to 25 + +OBX fields 21 to 25 are not supported by PCD PIV. + +====== Rate change, titration, Bolus from existing infusion, and Multistep + +======= Rate change or titration + +ORC-1 Order Control = “XO”. + +RXG-5 Give Amount-Minimum and RXG-7 Give Units must be empty. + +RXG-15, 16 must contain a rate or dose rate and cannot contain a dose. + +======= Bolus from existing infusion + +Considerations: + +* An infusion is currently programmed on the pump. +* A bolus of the same medication is ordered (i.e., there is a new order in the EHR). +* The EHR workflow provides the nurse the capability to administer the bolus from the same bag or syringe using the PIV [PCD-03] transaction to send the bolus order to the pump. +* No assumption is made about the behavior of the pump once the bolus has been delivered. Depending on the pump type or model it may stop, alarm, or resume delivering the underlying infusion. + +*ORC segment* + +* ORC-1 Order Control = “CH” (change) +* ORC-2 Placer Order Number = bolus order ID (child order ID) +* ORC-8 Parent = parent order ID + +A bolus order may be specified in 3 ways: + +* Dose or Volume + Rate +* Dose or Volume + Duration +* Rate + Duration + +The following table outlines the required and optional data for each type of bolus order. + +[width="100%",cols="14%,10%,10%,10%,10%,11%,20%,15%",options="header",] +|=== +|Bolus order type |ORC-1 |ORC-2 |ORC-8 |RXG-15/16 |TQ1 segment |_OBX segment with OBX-3 = MDC_INFUS_ ORDER_TYPE w/OBX-5 = clinician-dose_ |_OBX segment with OBX-3 = MDC_FLOW_ FLUID_PUMP_ +|Dose or volume + rate |“CH” |Bolus (child) order ID |Parent order ID |Dose or volume amount |O |R |R +|Dose or volume + duration |“CH” |Bolus (child) order ID |Parent order ID |Dose or volume amount |R |R |O +|Dose or volume |“CH” |Bolus (child) order ID |Parent order ID |Dose or volume amount |O |R |O +|Rate + duration |“CH” |Bolus (child) order ID |Parent order ID |Rate |R |R |O +|=== + +*OBX segment* + +* Include an OBX segment specifying the order type of bolus (clinician dose) where +* OBX-3 = MDC_INFUS_ORDER_TYPE. This term has enumerations in OBX-5 of “clinician-dose”, “loading-dose”, or “continuous”. +* When RXG-15 and RXG-16 specify a dose or a volume, any of the following three options are allowed: + +* include an OBX segment specifying the rate where OBX-3 = MDC_FLOW_FLUID_PUMP and OBX-5 = the desired rate +* include a TQ1 segment +* neither rate or duration is explicitly specified resulting in pump using predefined rate or duration determined by pump or operator. + +When the IPEC or DEC profiles contain information about a bolus from an existing infusion, note that the PCD-01 and PCD-10 messages contain bolus information in the Clinician Dose Info section. + +In the OBR segment, OBR-2 Placer Order Number contains the order ID of the bolus as a “child” order ID. OBR-29 Parent is used to contain the order ID for the parent (i.e., the existing infusion). + +======= Multistep + +The ordered medication and concentration must be identical in all steps. + +All steps are represented in the BCMA by a single order and a single order ID. + +Some pump models may support different dosing units (RXG-15 and 16) among steps (see Example 2 in the DEV TF vol 1, Section 4.4). + +*PCD-03 message structure* + +When used for multistep the HL7 RGV message structure used by PIV will require repetition of certain segments resulting in some duplication. + +The simplified message structure for multistep is shown below. + +\{} indicates repetition, [] indicates optionality. + +____ +MSH + +PID + +{empty}[PV1] + +ORC + +\{ + +RXG + +{empty}[TQ1] + +RXR + +OBX (multiple) + +} +____ + +Each step must contain: + +* Step number in RXG-1 (values are 1...n) +* An OBX segment to indicate the type of the current step + +* OBX-3 = MDC_INFUS_ORDER_STEP_TYPE +* enumerations are "loading dose" or "continuous" +* “loading dose” is optional and supported in step 1 only + +* An OBX segment to indicate the total number of steps in the program + +* OBX-3 = MDC_INFUS_TOTAL_NUM_STEPS + +* Additional OBX segments containing the pump ID or patient parameters (e.g., height, weight, BSA) as required + +The following table applies to how data is provided in PCD-01 and PCD-10 messages when the IPEC or DEC Profiles are used for a multistep infusion. + +[width="100%",cols="23%,34%,30%,13%",] +|=== +|Data |Term |Location within [PCD-01] or [PCD-10] message |Required +|Current step number |MDC_INFUS_ORDER_STEP_NUM |INFUSATE_SOURCE_* |Yes +|Total number of steps |MDC_INFUS_TOTAL_NUM_STEPS |INFUSATE_SOURCE_* |Yes +|Current step volume to be infused |MDC_VOL_STEP_TBI |INFUSATE_SOURCE_* | +|Current step volume delivered |MDC_VOL_STEP_DELIV |INFUSATE_SOURCE_* |Yes +|Current step volume remaining |MDC_VOL_STEP_REMAIN |INFUSATE_SOURCE_* | +|Total volume infused for all steps |MDC_VOL_FLUID_DELIV_TOTAL |INFUSATE_SOURCE_* |Yes +| | |* indicates the appropriate source | +|=== + +====== Expected Actions + +The Pharmacy/Treatment Give Message (RGV^O15^RGV_O15) is sent from the Infusion Order Programmer to the Infusion Order Consumer. + +The receiving system validates the message and responds with an accept acknowledgment message (ACK^O15^ACK) on the same port as the RGV^O15 message was received. The IOC also responds with a Pharmacy/Treatment Give Acknowledgement Message (RRG^O16^RRG_O16) on a new port and connection. If the message is accepted by the IOC, the accept acknowledgment will contain the value CA in MSA-1. If not, the accept acknowledgment will contain either CR or CE, based upon HL7 enhanced acknowledgment rules (see HL7 v2.6, Section 2.9.3.2). + +Message acceptance is based on: + +* All required segments and fields are present +* No incorrect data types are present. +* Validation of fields that must contain specific values as defined in the Technical Framework (e.g., MSH-21 must be "1.3.6.1.4.1.19376.1.6.1.3.1"). + +If applicable, the IOC may report an application acknowledgement error using the Pharmacy/Treatment Give Acknowledgement Message (RRG^O16^RRG_O16) for errors such as: + +* Unknown device +* Dose/rate and volume are not within vendor parameters for the device type. +* Drug is not present in onboard library. + +If the message from the Infusion Order Programmer is rejected, the acknowledgement will contain the value AR or AE in MSA-1**,** based upon HL7 enhanced acknowledgment rules (see HL7 v2.6, Section 2.9.2.2). The reason for rejection is provided in the ERR segment. + +Once the programming information is received by the pump, the clinician may choose to do one of the following: (1) confirm the settings on the pump and then start the infusion, (2) enter or modify one or more settings and then start the infusion, or (3) reject the program before it is started. + +Once the infusion is started, the settings actually programmed as well as the current state of the infusion can be obtained using the Communicate PCD Data [PCD-01] transaction. + +==== RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgement Message + +Table 3.3.5-1: RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgement Message + +[width="99%",cols="25%,30%,12%,11%,22%",options="header",] +|=== +|Segment |Meaning |Usage |Card |HL7 Chapter +|MSH |Message Header |R |[1..1] |2 +|MSA |Message Acknowledgment |R |[1..1] |2 +|[\{ ERR }] |Error |C |[0..1] |2 +|[\{ SFT }] |Software |X | |2 +|[\{ NTE }] |Notes and Comments (for Header) |X | |2 +|[ |--- RESPONSE begin | | | +|[ |--- PATIENT begin | | | +|PID |Patient Identification |O | |3 +|[\{ NTE }] |Notes and Comments (for PID) |X | |2 +|] |--- PATIENT end | | | +|\{ |--- ORDER begin | | | +|ORC |Common Order |O | |4 +|[\{ |--- TIMING begin | | | +|TQ1 |Timing/Quantity |X | |4 +|[\{ TQ2 }] |Timing/Quantity Order Sequence |X | |4 +|}] |--- TIMING end | | | +|[ |--- GIVE begin | | | +|RXG |Pharmacy/Treatment Give |X | |4 +|\{ |--- TIMING_GIVE begin | | | +|TQ1 |Timing/Quantity |X | |4 +|[\{ TQ2 }] |Timing/Quantity Order Sequence |X | |4 +|} |--- TIMING_GIVE end | | | +|\{ RXR } |Pharmacy/Treatment Route |X | |4 +|[\{ RXC }] |Pharmacy/Treatment Component |X | |4 +|] |--- GIVE end | | | +|} |--- ORDER end | | | +|] |--- RESPONSE end | | | +|=== + +===== MSH – Message Header Segment + +The MSH segment is defined in Appendix B.1 + +===== MSA - Message Acknowledgement segment + +The MSA segment is defined in Appendix B.2. + +===== ERR - Error segment + +The ERR Error segment is defined in Appendix B.3. + +=== Report Alert [PCD-04] + +In anticipation of HL7 2.8 item 625, Add Alert Trigger Event, this profile is making forward looking use of the triggers and events from that item, specifically the use of ORU^R40 for [PCD-04]. + +This section corresponds to transaction [PCD-04] of the IHE Devices Technical Framework. Transaction [PCD-04] is used by the Alert Reporter (AR), Alert Consumer (ACON) and the Alert Manager (AM) Actors. + +==== Scope + +This transaction is used by the Alert Reporter to report alerts to the Alert Manager (AM) and/or Alert Consumer (ACON). The Alert Reporter (AR) sends alerts to the Alert Manager (AM) and/or Alert Consumer (ACON) in an unsolicited manner. + +image:extracted-media-tf2/media/image7.emf[extracted-media-tf2/media/image7,width=485,height=280]image:extracted-media-tf2/media/image8.emf[extracted-media-tf2/media/image8,width=485,height=280]image:extracted-media-tf2/media/image9.emf[extracted-media-tf2/media/image9,width=485,height=280]image:extracted-media-tf2/media/image10.emf[extracted-media-tf2/media/image10,width=485,height=280]image:extracted-media-tf2/media/image11.emf[extracted-media-tf2/media/image11,width=485,height=280]image:extracted-media-tf2/media/image12.emf[extracted-media-tf2/media/image12,width=485,height=280]image:extracted-media-tf2/media/image13.emf[extracted-media-tf2/media/image13,width=485,height=280]image:extracted-media-tf2/media/image14.emf[extracted-media-tf2/media/image14,width=485,height=280]image:extracted-media-tf2/media/image15.emf[extracted-media-tf2/media/image15,width=485,height=280]image:extracted-media-tf2/media/image16.emf[extracted-media-tf2/media/image16,width=485,height=280]image:extracted-media-tf2/media/image17.emf[extracted-media-tf2/media/image17,width=485,height=280]image:extracted-media-tf2/media/image18.emf[extracted-media-tf2/media/image18,width=485,height=280] + +==== Use Case Roles + +[width="100%",cols="13%,87%",options="header",] +|=== +|*Actor* |Alert Reporter +|*Role* |Sends Report Alert to the Alert Manager (AM) +|*Actor* |Alert Manager (AM) +|*Role* |Receives Report Alert from Alert Reporter for transmission to a person +|*Actor* |Alert Consumer (ACON) +|*Role* |Receives Report Alert from Alert Reporter with no expectation of transmission to a person +|=== + +==== Referenced Standards + +HL7 - HL7 Version 2.6 Ch7 Observation Reporting + +ISO/IEEE 11073-10201 Domain Information Model + +ISO/IEEE 11073-10101 Nomenclature + +IEC 60601-1-8 Medical electrical equipment -- Part 1-8: General requirements for basic safety and essential performance -- Collateral standard: General requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems + +==== Messages + +===== Alert Reporter reports to Alert Manager/Alert Consumer + +image:extracted-media-tf2/media/image31.emf[extracted-media-tf2/media/image31] + +Alert Reporter sends Report Alert to Alert Manager and/or Alert Consumer as an HL7 ORU message. + +====== HL7 Conformance Statement + +The conformance statement for this interaction described below is adapted from HL7 2.6. + +Table 3.4.4.1.1-1: PCD-04 Transaction Conformance + +[width="100%",cols="45%,55%",options="header",] +|=== +|Publication ID: |R40 +|Type: |Unsolicited +|Publication Name: |IHEPCD-04ReportAlert +|Trigger: |None +|Mode: |Immediate +|Response: |ORU^R40^ORU_R40 +|Characteristics: |Sends defined alert data +|Purpose: |Report Alert from Alert Reporter to Alert Manager and/or Alert Consumer +|Based on Segment Pattern: |R40 +|=== + +====== PCD-04 Report Alert (ORU^R40^ORU_R40) static definition + +The Report Alert [PCD-04] message is used to communicate ACM data from an Alert Reporter (AR) to Alert Manager (AM) and/or Alert Consumer (ACON) + +Common HL7 segments are defined in Appendix B Common Message Segments. There are sections discussing considerations specific to [PCD-04] where applicable. + +Table 3.4.4.1.2-1: ORU^R40^ORU_R40 HL7 Attribute Table + +[width="100%",cols="13%,39%,16%,15%,17%",options="header",] +|=== +|Segment |ORU Message |Usage |Card. |HL7 Ref +|MSH |Message Header Segment |R |[1..1] |2.15.9 +|PID |Patient Identification Segment |CE |[0..1] |3.4.2 +|PV1 |Patient Visit Segment |CE |[0..1] |3.4.3 +|[ORC] |Common Order Segment |O |[0..1] |4.5.1 +|OBR |Observation Request Segment |R |[1..n] |7.4.1 +|[PRT] |Participation Segment |O |[0..n] |8.4.4 (V2.7) +|OBX |Observation Result Segment |R |[1..n] |7.4.2 +|[NTE] |Notes and Comments Segment |O |[0..1] |2.5.10 +|=== + +While there can be multiple OBR segments per [PCD-04] transaction (in support of inclusion of alert common containment and evidentiary data) there is at most one alert per [PCD-04] transaction. + +Table 3.4.4.1.2-2: ORU^R40^ORU_R40 Static Definition + +[width="100%",cols="47%,53%",options="header",] +|=== +|ORU^R40^ORU_R40 |Report Alert Message +|MSH |Message Header +|[\{SFT}] |Software Segment +|\{ |--- ALERT begin +|[ |--- PATIENT begin +|PID |Patient Identification +|[ |--- LOCATION begin +|PV1 |Alert Location +|] |--- LOCATION end +|] |--- PATIENT end +|\{ |--- ALERT_IDENTIFICATION begin +|[ORC] |Alert Order Common +|\{OBR} |Alert Identification +|[ \{ |--- ALERT_OBSERVATION begin +|\{OBX} |Alert observations relative to OBR +|[PRT] |Participation identifies additional notification recipients +|\{ [NTE] } |Notes and Comments +|}] |--- ALERT OBSERVATION end +|} |--- ALERT_IDENTIFICATION end +|} |--- ALERT end +|=== + +A single Report Alert [PCD-04] transaction contains at most one alert for a given patient and there must be an OBR preceding each group of OBX segments. + +See Appendix B for details of the contents of each segment in the [PCD-04] transaction. + +====== Trigger Events + +The trigger event for a [PCD-04] transaction is that the Alert Reporter has detected the presence, onset, continuation of, or conclusion an event which may be an alert and sends it to the Alert Manager and/or Alert Consumer. + +====== Message Semantics + +This message is meant to convey from the Alert Reporter to the Alert Manager and/or the Alert Consumer, the fact that an alert is present, occurring, is still occurring, or has ended along with the data related to the alert to identify the patient and/or location, the alerting condition, and any observations associated with the alert. + +====== Expected Actions + +HL7 ACK from the Alert Manager (AM) and/or the Alert Consumer (ACON) back to the Alert Reporter (AR) is used to communicate that the Alert Manager (AM) and/or the Alert Consumer has received the Report Alert [PCD-04] message from the Alert Reporter (AR). Report Dissemination Alert Status [PCD-07] transactions that are responses to a particular Report Alert [PCD-04] are not rapid synchronous responses to it; since they depend on events that may take an indeterminate amount of time, including in some cases responses by a person receiving the alert. That is the reason that an HL7 ACK is not used to report dissemination status of the alert as this procedure would leave the Alert Reporter (AR) awaiting HL7 ACK receipt for an indeterminate amount of time. + +Status updates as to the dissemination of the alert are optional and are communicated using the Report Alarm Status [PCD-05] transaction from the Alert Manager (AM) to the Alert Reporter (AR). + +While the Alert Reporter to Alert Manager and/or Alert Consumer PCD-04 is one message it is likely to result in many PCD-06 messages from Alert Manager to Alert Communicator and many PCD-07 messages from Alert Communicator back to Alert Manager and many PCD-05 messages from Alert Manager back to Alert Reporter. + +If the Alert Manager implements escalation to additional recipients based upon internally defined lack of delivery status updates or lack of operator responses then those additional [PCD-06] transactions from the Alert Manager to the Alert Communicator are likely to result in additional PCD-05 messages from the Alert Manager back to the Alert Reporter. + +Communication device operator response delays may result in delays of Alert Communicator to Alert Manager and Alert Manager back to Alert Reporter messages. + +Instances of the Participation Information Segment (PRT) are optionally used by the Alert Reporter (AR) in the PCD-04 message to indicate alert notification recipients which are in addition to any alert notification recipients identified internally by the Alert Manager (AM). + +====== Security Considerations + +During the profile development there were no unusual security/privacy concerns identified. There are no mandatory security controls, but the implementer is encouraged to use the underlying security and privacy profiles from ITI that are appropriate to the transports such as the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk assessment, following ISO 80001, will determine the actual security and safety controls employed. + +An optional instance of the OBX segment with a specific observation indication can be included in the Report Alert [PCD-04] transaction by the Alert Reporter (AR) Actor to communicate a filter to the Alert Manager (AM) Actor to constrain the types of alert dissemination status update Report Alert Status [PCD-05] transactions sent by the Alert Manager (AM) Actor to the AR Actor in response to the Alert Manager (AM) Actor receiving Report Alert Dissemination Status [PCD-07] transactions from the Alert Communicator (AC) Actor. See Appendix B for details. + +=== Report Alert Status [PCD-05] + +This section corresponds to transaction [PCD-05] of the IHE Devices Technical Framework. Transaction [PCD-05] is used by the Alert Manager (AM) to report alert communication, status updates, and operator responses to the Alert Reporter (AR). + +==== Scope + +This transaction is used by the Alert Manager (AM) to report one or more dissemination status updates back to the Alert Reporter. + +==== Use Case Roles + +Actor: Alert Manager (AM) + +Role: Sends Report Alert Status to Alert Reporter (AR) + +Actor: Alert Reporter (AR) + +Role: Receives Report Alert Status from the Alert Manager (AM) + +==== Referenced Standard + +HL7 - HL7 Version 2.6 Ch7 Observation Reporting + +ISO/IEEE 11073-10201 Domain Information Model + +ISO/IEEE 11073-10101 Nomenclature + +==== Messages + +image:extracted-media-tf2/media/image32.emf[extracted-media-tf2/media/image32,width=503,height=304] + +Figure 3.5.4-1: ACM Interaction Diagram + +===== Alert Manager status updates to Alert Reporter + +The Alert Manager sends Report Alert Status transactions to the Alert Reporter as an HL7 message. + +====== Trigger Events + +The Alert Manager has determined either through configuration and contextual data driven decision rules or through receipt of Report Dissemination Alert Status from the Alert Communicator that an alert status update needs to be sent to the Alert Reporter. + +Alert Manager internal trigger events include the following: + +* Accept (not specified, correct) +* Reject (not specified, nuisance but correct, false positive) +* Deliverable, had a mapped destination +* Undeliverable, couldn’t communicate message to endpoint device +* Queued to communications + +====== Message Semantics + +This message is meant to convey from the Alert Manager to the Alert Reporter the dissemination and response status of the alert message back for the Alert Reporter. + +====== HL7 Conformance Statement + +The conformance statement for the interaction described below is adapted from HL7 2.6 with the addition of the PRT segment from 2.7 + +In conformance with the released version of HL7 2.8 the ACM Profile Report Alert Status [PCD-05] transaction which reports alert notification delivery and response status from the Alert Communicator back through the Alert Manager (AM) to the Alert Report (AR) uses trigger R41 with message type ORA and a message template of ORA_R1 for an effective MSH-9 field value of ORA^R41^ORA_R41. + +A template of R41 is required as the R01 template is not sufficiently flexible in communicating the multiple patient, location, device and logging stimulus use cases of the ACM Profile. + +In an R41 the Participation Information (PRT) segment PRT-4 field AAP (Alert Acknowledging Provider) is used to indicate the identity of the person to which the alert has been delivered and/or acknowledged. The information source for delivery confirmation and response information for the potentially multiple [PCD-05] transactions content is the potentially multiple [PCD-07] transactions from the Alert Communicator (AC) to the Alert Manager (AM). + +Table 3.5.4.1.3-1: Transaction Conformance + +[width="100%",cols="34%,66%",options="header",] +|=== +|Publication ID: |R41 +|Type: |Unsolicited +|Publication Name: |IHEPCD-05ReportAlarmStatus +|Trigger: |None +|Mode: |Immediate +|Response: |ORA^R41^ORA_R41 +|Characteristics: |Sends alarm status data +|Purpose: |Provide alarm status from Alert Manager to Alert Reporter +|Based on Segment Pattern: |R41 +|=== + +====== PCD-05 Report Alert Status (ORA^R41^ORA_R41) static definition + +The PCD-05 Report Alert Status message is used to communicate ACM messaging status from an Alert Manager (AM) to an Alert Reporter (AR) + +Common HL7 segments are defined in Appendix B Common Message Segments. + +Table 3.5.4.1.4.-1: ORA^R41^ORA_R41 static definition + +[width="100%",cols="30%,24%,11%,16%,19%",options="header",] +|=== +|ORA^R41^ORA_R41 |ORU Message |Usage |Card. |Section Ref +|MSH |Message Header Segment |R |[1..1] |2.15.9 +|MSA |Message Acknowledgement |R | | +|PID |Patient Identification Segment |CE |[0..1] |3.4.2 +|PV1 |Patient Visit Segment |CD |[0..1] |3.4.3 +|[ORC] |Common Order Segment |O |[0..1] |4.5.1 +|OBR |Observation Request Segment |R |[1..n] |7.4.1 +|[PRT] |Participation Information Segment |CE |[0..1] |HL7 2.7 7.4.4 +|OBX |Observation Result Segment |O |[0..n] |7.4.1 +|[NTE] |Notes and Comments Segment |O |[0..1] |2.5.10 +|=== + +While there can be multiple OBR segments per transaction there is at most one alert on which status is reported per transaction. + +For traceability the value in the MSA-2 Message Control ID field shall be the value of the MSH-10 Message Control ID field of the original PCD-04 message where the alert phase is indicted as start, start only, or present and not the ID of any updates to that [PCD-04] message or of any [PCD-05] transaction message instances. The content of MSA-2 is the identification of the [PCD-04] transaction for which the [PCD-05] transaction is providing application level acknowledgement and there can be more than one given the one-to-many relationship between [PCD-04] and [PCD-05] transactions. + +For HL7 message receipt acknowledgement of the [PCD-05] transaction the AR Actor should use the contents of the MSH-10 Message Control ID field of the [PCD-05] transaction. + +The Alert Manager (AM) Actor does not have the awareness to realistically determine the total number of expected or outstanding [PCD-05] instances. This is due to the ability of the AC Actor to instantiate additional alert disseminations and the endpoint communication devices being an unknown mix of those both supporting and not supporting specific responses (Delivery confirmation, Read receipt). Additionally, polling is discouraged as it introduces unwanted delays in patient life safety notifications. Therefore the MSA-7 Message Waiting Number and MSA-8 Message Waiting Priority fields shall both be empty. + +====== Expected Actions + +Alert Reporter takes appropriate action based upon alert status update. At a minimum, this shall include the Alert Reporter logging receipt of the PCD-05 message. + +Actions by the Alert Reporter to indicate whether or not the alert notification text message was successfully disseminated (not possible with one-way pager devices), the identification of the recipients (not possible if notification assignments are by device identification and not by person identification), and how they responded (not possible with one-way pager devices) would be informative, but is not a requirement of this profile. + +image:extracted-media-tf2/media/image33.emf[extracted-media-tf2/media/image33,width=624,height=768] + +====== Security Considerations + +This profile while utilizing communication capabilities supportive of authentication, encryption, or auditing, does not impose specific requirements leaving these matters to site-specific policy or agreement. The IHE Devices Technical Framework identifies security requirements across all PCD profiles. During the Profile development there were no unusual security/privacy concerns identified. There are no mandatory security controls, but the implementer is encouraged to use the underlying security and privacy profiles from ITI that are appropriate to the transports such as the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk assessment, following ISO 80001, will determine the actual security and safety controls employed. + +=== Disseminate Alert [PCD-06] + +This section corresponds to transaction [PCD-06] of the IHE Devices Technical Framework. Transaction [PCD-06] is used by the Alert Manager (AM) to disseminate alerts to the Alert Communicator (AC). + +==== Scope + +This transaction is used by Alert Manager (AM) to disseminate the alert to the Alert Communicator (AC). + +==== Use Case Roles + +[width="100%",cols="13%,87%",options="header",] +|=== +|*Actor* |Alert Manager (AM) +|*Role* |Sends Disseminate Alert to Alert Communicator (AC) +|*Actor* |Alert Communicator (AC) +|*Role* |Receives Disseminate Alert from the Alert Manager (AM) +|=== + +==== Referenced Standard + +The communication protocol between the Alert Manager and Alert Communicator Actors shall be WCTP. The communicated data items are in scope for this profile (for details see Appendix K Message Transport Using WCTP (ACM Transactions [PCD-06] and [PCD-07])). See the current version of IHE PCD Rosetta Terminology Mapping (RTM) for the list of standardized alert terms that may be used within PCD-04 messages (see the NIST Rosetta Terminology Mapping Management Service websites, http://rtmms.nist.gov[[.underline]#http://rtmms.nist.gov#]). + +While alert related data items available to the Alert Manager are specified in this profile, the ability of individual communication devices to communicate, display, or respond to those data items is dependent upon the product capabilities and site-specific configuration of the Alert Communicator, the communication device, and the available communication infrastructure. + +The base standard for Alert Manager to Alert Communicator communication is Wireless Communications Transfer Protocol (WCTP) Protocol Specification version 1.3 update 1 (http://www.wctp.org/release/wctp-v1r3_update1.pdf) + +ISO/IEEE 11073-10201 Domain Information Model + +ISO/IEEE 11073-10101 Nomenclature + +==== Messages + +===== Alert Manager disseminate alert to Alert Communicator + +Alert Manager sends Disseminate Alert to Alert Communicator. The protocol between the Alert Manager and Alert Communicator Actors shall be WCTP. + +====== HL7 Conformance Statement + +The communication protocol shall be WCTP. There is therefore no specified HL7 conformance. + +====== PCD-06 Disseminate Alert static definition + +The PCD-06 Disseminate Alert message is used to communicate ACM data from an Alert Manager (AM) to the Alert Communicator (AC). + +The text message within the [PCD-06] transaction is meant to be readily recognized and acted upon by people. Accordingly, it should be as short as can be made while still conveying the important information, and easily understood by the intended recipients. Most communication device displays are limited in size; so long messages are undesirable as they require scrolling to review the entire message before acting upon it to make sure that no pertinent information is overlooked. + +If the [PCD-06] includes a human readable text description of the alert indication, that is the preferred description to be presented on the wireless endpoint communication device. In the absence of such information, the Alert Manager should produce the human readable text description from other information present in the transaction. + +In planning the use of this transaction, implementers should assure that regulatory requirements and institutional policy regarding the protection of personal health information are properly accounted for including any need for authentication or encryption of the communications. + +====== Trigger Events + +The Alert Manager has determined that an alert needs to be disseminated and so sends it to each Alert Communicator endpoint device associated with the mapping of the alert source to the alert notification destination. + +====== Message Semantics + +This message communicates alerts to communication endpoint devices. + +The table below lists the data items and their optionality. All of these data items are within the WCTP message text. + +Table 3.6.4.1.4-1: PCD-06 static definition + +[width="100%",cols="30%,41%,11%,18%",options="header",] +|=== +|PCD-06 |Fields |Usage |Card. +|Alert_Location |Alert associated location based upon information from PV1-3 |CE |[0..1] +|Alert_Patient |Patient Identification |CE |[0..1] +|Alert_Text |Textual alert identification |R |[1..1] +|Alert_Identifier |Alert unique identifier |O |[0..1] +|Alert_Callback |Call back connection information |O |[0..1] +|Alert_Reference |URL or application link potentially containing alert or patient contextual information |O |[0..1] +|Alert_Comment |Notes and Comments associated with alert |O |[0..1] +|Alert_Evidentiary_Data a| +Evidentiary data (WCM) associated with alert content + +See Appendix K for WCTP messaging information + +|O |[0..1] +|Alert_Graphical_Snippet a| +Graphical snippet associated with Alert (WCM) content + +See Appendix K for WCTP messaging information + +|O |[0..n] +|Alert_Information |Information associated with alert content, See Appendix K for WCTP messaging information |O |[0..1] +|=== + +====== Expected Actions + +Alert Communicator sends alert to endpoint. If the endpoint is a group then the Alert Communicator is expected to send the alert notification to all members of the group. + +====== Security Considerations + +This profile while utilizing communication capabilities supportive of authentication, encryption, or auditing, does not impose specific requirements leaving these matters to site-specific policy or agreement. During the Profile development there were no unusual security/privacy concerns identified. There are no mandatory security controls, but the implementer is encouraged to use the underlying security and privacy profiles from ITI that are appropriate to the transports such as the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk assessment, following ISO 80001, will determine the actual security and safety controls employed. + +=== Report Dissemination Alert Status [PCD-07] + +This section corresponds to transaction [PCD-07] of the IHE Devices Technical Framework. Transaction [PCD-07] is used by the Alert Communicator to signal dissemination status updates and replies to the Alert Manager (AM). + +==== Scope + +This transaction is used by Alert Communicator to report one or more dissemination status updates and/or replies to the Alert Manager (AM). A single [PCD-06] transaction from the Alert Manager to the Alert Communicator can result in numerous [PCD-07] transactions from the Alert Communicator back to the Alert Manager. + +==== Use Case Roles + +[width="100%",cols="14%,86%",options="header",] +|=== +|*Actor* |Alert Communicator (AC) +|*Role* |Sends Dissemination Status to the Alert Manager (AM) +|*Actor* |Alert Manager (AM) +|*Role* |Receives Dissemination Status from the Alert Communicator (AC) +|=== + +==== Referenced Standards + +WCTP version 1.3 update 1 + +ISO/IEEE 11073-10201 Domain Information Model + +ISO/IEEE 11073-10101 Nomenclature + +IEC 60601-1-8 Medical electrical equipment -- Part 1-8: General requirements for basic safety and essential performance -- Collateral standard: General requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems + +The communication protocol is WCTP, the same as for the Disseminate Alert [PCD-06] transaction. See Appendix K, Message Transport Using WCTP (ACM Transactions [PCD-06] and [PCD-07]) for details. + +==== Messages + +===== Alert Communicator status updates to Alert Manager + +The Alert Communicator sends Dissemination Status to the Alert Manager. The protocol utilized is WCTP. + +===== Trigger Events + +The Alert Communicator has determined a dissemination status update needs to be sent to the Alert Manager. + +The following table lists the results of the dissemination from the Alert Communicator back to the Alert Manager. The required Communication Status Enumerations are indicated. + +Table 3.7.4.2-1: Status Enumerations + +[width="100%",cols="16%,84%",options="header",] +|=== +|Usage |Communication Status Enumeration +|R |Received by communications (accepted by WCTP gateway) +|O a| +Undeliverable to endpoint + +Optional in support of one-way devices, such as pagers. + +|O a| +Delivered to endpoint + +Optional in support of one-way devices, such as pagers. + +|O a| +Read at endpoint + +Optional in support of one-way devices, such as pagers. + +|O a| +Accepted by endpoint + +Optional in support of one-way devices, such as pagers. + +|O |Accepted by endpoint as true positive +|O |Accepted by endpoint as true positive however not clinically relevant +|O |Accepted by endpoint as false positive +|O a| +Rejected by endpoint + +Optional in support of one-way devices, such as pagers. + +|O |Cancelled by endpoint +|O |Cancelled by other than endpoint +|O a| +Callback start at endpoint + +See Appendix K for WCTP messaging details. + +Optional as not supported by all notification devices. + +|O a| +Callback end at endpoint + +See Appendix K for WCTP messaging details. + +Optional as not supported by all notification devices. + +|O a| +Completed by endpoint operator + +Optional in support of one-way devices, such as pagers. + +|=== + +A single [PCD-04] to [PCD-06] transaction may go through multiple communications status updates as the alert is communicated to the endpoint user or application. Which of the status updates are possible depends on the capabilities of the Alert Communicator and endpoint. Some endpoint devices are output only and do not support two-way capabilities, while other devices and services offer transmission confirmation. More advanced communications endpoints offer two-way capabilities allowing the operator of the endpoint to accept or cancel the alert. + +An Alert Communicator Actor might maintain internal alert dissemination recipient lists in addition to the dissemination recipient mappings of the Alert Manager. This might be the case if the Alert Communicator is a commercial message dissemination service provider. The Alert Manager Actor might not be aware of all of the individual recipients in such lists. This may result in additional PCD-07 Report Dissemination Alert Status transactions being sent by the Alert Communicator to the Alert Manager for which there was no recipient specific PCD-06 transaction from the Alert Manager to the Alert Communicator. These additional PCD-07 transactions may result in additional PCD-05 Report Alert Status transactions being sent from the Alert Manager to the Alert Reporter. + +Detailed reason for status can optionally be included in the WCTP errorText element to account for messages not reaching the endpoint, or being rejected by the endpoint, because the device is known to be offline or in a busy or do not disturb state. See details in WCTP interface specification. + +====== Message Semantics + +This message is used to communicate status updates on the communication of an alert to endpoints. See Appendix K for WCTP messaging specifics. + +====== HL7 Conformance Statement + +The communication protocol is WCTP; therefore, there is no specified HL7 conformance. + +====== PCD-07 Report Dissemination Alert Status static definition + +The PCD-07 Dissemination Status message is used to communicate ACM messaging status and replies from an Alert Communicator (AC) to Alert Manager (AM) + +The Alert Communicator (AC) is not responsible for indicating that the endpoint operator has received but not responded to the notification – as in sending “delivered to device” status, automatically displayed, which may or may not send back read indication, but no operator interaction. Actions for non-response by the Alert Communicator (AC) endpoint operator (clinical user) (escalation or sending to alternate devices) is within the scope of the Alert Manager (AM). Such actions have been identified within the ACM Profile as out of scope. + +The endpoint device message communication protocol between the Alert Communicator and the endpoint device is outside the scope of the profile. The data presentation by the endpoint device is outside the scope of the profile. + +The table below lists the data items and their optionality. + +Table 3.7.4.2.3-1: PCD-07 static definition + +[width="100%",cols="24%,46%,12%,18%",options="header",] +|=== +|PCD-07 |ORU Message |Usage |Card. +|Alert _Identifier a| +Alert unique identifier + +(see [PCD-06]) + +|R |[1..1] +|Alert _Status |Communication Status Enumeration item |R |[1..1] +|Alert_Information |Information associated with alert content, see Appendix K for WCTP messaging information |O |[0..1] +|=== + +====== Expected Actions + +Based upon the status of the delivery or the operator response the Alert Manager may effect changes in its own internal escalation process to select and send the message to a different device associated with the same user or a device associated with a different user. + +If the Alert Manager supports the PCD-05 message then in response to each PCD-07 message a PCD-05 message is sent from the Alert Manager to the Alert Reporter to update the Alert Reporter as to alert dissemination status updates and operator responses to the alert PCD-06 message. + +====== Security Considerations + +This profile while utilizing communication capabilities supportive of authentication, encryption, or auditing, does not impose specific requirements leaving these matters to site-specific policy or agreement. The IHE Devices Technical Framework identifies security requirements across all PCD profiles. During the profile development there were no unusual security/privacy concerns identified. There are no mandatory security controls, but the implementer is encouraged to use the underlying security and privacy profiles from ITI that are appropriate to the transports such as the Audit Trail and Node Authentication (ATNA) Profile. The operational environment risk assessment, following ISO 80001, will determine the actual security and safety controls employed. + +=== [PCD-08] Reserved + +=== Communicate IDC Observations [PCD-09] + +This section corresponds to transaction [PCD-09] of the IHE Devices Technical Framework. Transaction [PCD-09] is used by the Implantable Device – Cardiac – Reporter and Implantable Device – Cardiac – Consumer Actors. + +==== Scope + +In the Communicate IDC Observation transaction, the Implantable Device – Cardiac – Reporter sends the observation as an unsolicited HL7 ORU message to the Implantable Device – Cardiac – Consumer. + +==== Use Case Roles + +Figure 3.9.2-1: Communicate IDC Observation + +[width="100%",cols="15%,85%",options="header",] +|=== +|*Actor* |Implantable Device – Cardiac – Reporter +|*Role* |Outputs the Observation as an HL7 ORU message upon completion of the observation. This message contains the discrete data for the observation and/or a PDF document containing displayable data relating to the observation. +|*Actor* |Implantable Device – Cardiac – Consumer +|*Role* |Receives the HL7 ORU message and provides some implementation-specific processing. This may include creation of reports, integration of information into electronic health records, or creation of derived data (trends, analyses, reformatted data, population statistics, etc.). If needed, it will reconcile patient identification using an implementation-specific mapping function. +|=== + +==== Referenced Standard + +HL7 Messaging Standard v2.6 + +Note: The IDCO is functional with HL7 Messaging Standard v2.5. The only change required is when specifying in the message header which version is being used. + +ISO 19005-1. Document management – Electronic document file format for long-term preservation – Part 1: Use of PDF (PDF/A) + +UCUM: Unified Code for Units of Measure, Regenstrief Institute for Health Care, Indianapolis 2005. Version 1.6 + +IEEE 11073_10103 MDC_IDC Nomenclature + +==== Messages + +image:extracted-media-tf2/media/image34.emf[extracted-media-tf2/media/image34,width=538,height=239] + +===== HL7 ORU Observation + +This is a standard HL7 v2.6 unsolicited orders and observation message containing the observations taken by the implanted device. Information is coded using the IEEE 11073-10103 IDC Nomenclature. + +====== Trigger Events + +[width="100%",cols="18%,28%,24%,14%,16%",options="header",] +|=== +|ORU |Observation Results Message |Usage |Card |HL7 Spec Chapter +|MSH |Message Header | |[1..1] |2 +|[\{ SFT }] |Software Segment | |[0..1] |2 +|PID |Patient Identification |Demographics for id matching |[1..1] |3 +|[ PV1 ] |Patient Visit | |[0..1] |3 +|\{ |Order Observation Repeat Grouping BEGIN | |[1..*] | +|OBR |Observations Request |Clinical context |[1..1] |7 +|\{[NTE]} |Notes Section |Notes related to OBR |[0..*] | +|\{OBX} |Observation results |Observations related to the pulse generator |[0..*] |7 +|\{[NTE]} |Notes Section |Notes Related to OBX |[0..*] | +|} |Order Observation Repeat Grouping END | | | +|[DSC] |Continuation Pointer | |[0..0] |2 +|=== + +The Implantable Device – Cardiac – Reporter initiates the HL7 ORU message to the Implantable Device – Cardiac – Consumer following an implanted cardiac device interrogation. + +====== Message Semantics + +The message is an unsolicited v2.6 ORU message from the Implantable Device – Cardiac – Reporter to the Implantable Device – Cardiac – Consumer with a corresponding ACK message back to the Implantable Device – Cardiac – Reporter. The contents of the message (in OBX segments) are a required set of individual observations or measurements trans-coded into separate HL7 v2.6 OBX segments and an optional encapsulated PDF document. + +Refer to the HL7 v2.6 Standard, Chapter 7 ORU Message for general message semantics. + +The constrained message structure is given in Table 3.9.4.1.2-1, with additional details provided in sections below. + +Table 3.9.4.1.2-1: ORU Message Structure + +[width="100%",cols="12%,31%,30%,8%,19%",options="header",] +|=== +|ORU |Observation Results Message |Usage |Card |HL7 Spec Chapter +|MSH |Message Header | |[1..1] |2 +|[\{ SFT }] |Software Segment | |[0..1] |2 +|PID |Patient Identification |Demographics for id matching |[1..1] |3 +|[ PV1 ] |Patient Visit | |[0..1] |3 +|\{ |Order Observation Repeat Grouping BEGIN | |[1..*] | +|OBR |Observations Request |Clinical context |[1..1] |7 +|[NTE]} |Notes Section |Notes related to OBR |[0..*] | +|\{OBX} |Observation results |Observations related to the pulse generator |[0..*] |7 +|[NTE]} |Notes Section |Notes Related to OBX |[0..*] | +|} |Order Observation Repeat Grouping END | | | +|[DSC] |Continuation Pointer | |[0..0] |2 +|=== + +======= 3.9.4.1.2.1 MSH Segment – Message Header + +Table 3.9.4.1.2.1-1: MSH Segment + +[width="100%",cols="20%,8%,6%,7%,7%,8%,7%,8%,8%,9%,12%",options="header",] +|=== +| |Seq |DT |Len |Opt |Rep |Min |Max |Tbl |Fixed |Ex Val +|Field Separator |1 |ST |1 |R |False |1 |1 | |Y |\| +|Encoding Characters |2 |ST |4 |R |False |1 |1 | |Y |^~\& +|Sending Application |3 |HD |227 |RE |False |0 |1 |0361 | | +|namespace ID |_1_ |IS |20 |O | |0 |1 |0300 | |APP NAME +|Sending Facility |4 |HD |227 |RE |False |0 |1 |0362 | | +|namespace ID |_1_ |IS |20 |O | |0 |1 |0300 | |VENDOR NAME +|Receiving Application |5 |HD |227 |RE |False |0 |1 |0361 | | +|namespace ID |_1_ |IS |20 |O | |0 |1 |0300 | |CLINIC APPLICATION +|Receiving Facility |6 |HD |227 |RE |False |0 |1 |0362 | | +|namespace ID |_1_ |IS |20 |O | |0 |1 |0300 | |CLINIC ID +|Date/Time of Message |7 |TS |26 |R |False |1 |1 | | | +|time |_1_ |DTM |24 |R | |1 |1 | | |20040328134623.1234+0300 +|Message Type |9 |MSG |15 |R |False |1 |1 | | | +|message code |_1_ |ID |3 |R | |1 |1 |0076 |Y |ORU +|trigger event |_2_ |ID |3 |R | |1 |1 |0003 |Y |R01 +|message structure id |_3_ |ID |3 |R | |1 |1 |0003 |Y |ORU_R01 +|Message Control ID |10 |ST |20 |R |False |1 |1 | | |1234567890 +|Processing ID |11 |PT |3 |R |False |1 |1 | | | +|processing ID |_1_ |ID |1 |R | |1 |1 |0103 |Y |P +|Version ID |12 |VID |971 |R |False |1 |1 | | | +|version ID |1 |ID |5 |R | |1 |1 |0104 |Y |2.6 +|=== + +Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type. + +======= 3.9.4.1.2.2 PID Segment – Patient Identification + +Table 3.9.4.1.2.2-1: PID Segment + +[width="100%",cols="19%,8%,8%,7%,7%,8%,6%,8%,8%,9%,12%",options="header",] +|=== +|Name |Seq |DT |Len |Opt |Rep |Min |Max |Tbl |Fixed Val |Ex Val +|Set ID - PID |1 |SI |4 |O | |0 |1 | | | +|Patient Identifier List |3 |CX |250 |R |True |1 |* | | | +|ID number |_1_ |ST |199 |R | |1 |1 | | |MODEL:XXX/SERIAL:XXX +|Assigning authority |_4_ |HD |227 |R | |1 |1 |0363 | |BSC +|identifier type code |_5_ |ID |5 |O | |0 |1 |0203 | |U +|Patient Name |5 |XPN |294 |RE |True |1 |* | | | +|family name |_1_ |FN |194 |O | |0 |1 | | |DOE +|given name |_2_ |ST |30 |O | |0 |1 | | |JOHN +|second and further given names or initials thereof |_3_ |ST |30 |O | |0 |1 | | |S +|suffix (e.g., JR or III) |_4_ |ST |20 |O | |0 |1 | | |JR +|Date/Time of Birth |7 |TS |26 |RE |False |0 |1 | | | +|time |_1_ |DTM |24 |RE | |1 |1 | | |19600328 +|Administrative Sex |8 |IS |1 |RE |False |0 |1 |0001 | |M +|Patient Address |11 |XAD |513 |RE |True |0 |* | | | +|street address |_1_ |SAD |184 |O | |0 |1 | | |12345 Some Street +|other designation |_2_ |ST |120 |O | |0 |1 | | |Apartment 123 +|city |_3_ |ST |50 |O | |0 |1 | | |Town +|state or province |_4_ |ST |50 |O | |0 |1 | | |MN +|zip or postal code |5 |ST |12 |O | |0 |1 | | |12345  +|country |6 |ID |3 |O | |0 |1 |0399 | |USA +|=== + +Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type. + +*PID-3.1 Patient Identifier List* + +ID Number contains a unique identifier for the patient assigned by the Implantable Device – Cardiac – Reporter. Identifier Type Code is constrained by Table 0203 listed below (others can be included as defined in the 2.6 standard). The first identifier will always be the unique model/serial number of the implanted device with an identifier of type U (see table following). This will be used by the Implantable Device – Cardiac – Consumer / Repository to match the device interrogations with the patient accounts. Assigning Authority will be a unique name of the Implantable Device – Cardiac – Reporter system or owning organization that creates the observation and will be coded using the MDC_IDC Nomenclature, MDC_IDC_DEV_MFG term. + +Table 3.9.4.1.2.2-2: HL7 Table 0203 + +[width="99%",cols="12%,32%,46%,10%",options="header",] +|=== +|Code |Description |Notes |Usage +|U a| +Model and Serial Number of Device + +IEEE 11073_10103 MDC_IDC_DEV_MODEL and MDC_IDC_DEV_SERIAL + +a| +Model and Serial number will be concatenated together and will be unique within an Assigning Authority. + +The format of the ID will be following: + +"model:xxx/serial:yyy" + +Example: model:XZY987/serial:abc123 + +|R +|SS |Patient Social Security Number |Social Security number will be included if known. |RE +|=== + +======= 3.9.4.1.2.3 PV1 Segment – Patient Visit (Optional) + +Table 3.9.4.1.2.3-1: PV1 Segment + +[width="100%",cols="21%,8%,8%,7%,7%,8%,7%,8%,7%,9%,10%",options="header",] +|=== +|Name |Seq |DT |Len |Opt |Rep |Min |Max |Tbl |Fixed Value |Ex Val +|Set ID - PV1 |1 |SI |4 |O |False |0 |1 | | |1 +|Patient Class |2 |IS |1 |R |False |1 |1 |0004 | |R +|Attending Doctor |7 |XCN |309 |O |True |0 |* |0010 | | +|ID number |_1_ |ST |15 |O | |0 |1 | | |MWELBY +|family name |_2_ |FN |194 |O | |0 |1 | | |Welby +|given name |_3_ |ST |30 |O | |0 |1 | | |Marcus +|second and further given names or initials thereof |_4_ |ST |30 |O | |0 |1 | | |A +|suffix (e.g., JR or III) |_5_ |ST |20 |O | |0 |1 | | |III +|prefix (e.g., DR) |_6_ |ST |20 |O | |0 |1 | | |DR +|Visit Number |19 |CX |250 |O |False |0 |1 | | | +|ID number |_1_ |ST |15 |O | |0 |1 | | |123456 +|=== + +Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type. + +Because this is an unsolicited observation and the Implantable Device – Cardiac – Reporter will not be aware of an associated order, this segment is optional. The Implantable Device – Cardiac – Reporter may want to track the interrogation as a visit using this segment. If information is provided here it will match corresponding information provided in the OBX segments. + +PV1-7 Attending Doctor will optionally be captured by the Implantable Device – Cardiac – Reporter. If present, PV1-7.1 Attending Doctor ID Number will be a unique identifier for each doctor in the context of the Implantable Device – Cardiac – Reporter, not the Implantable Device – Cardiac – Consumer. + +PV1-19 Visit Number, ID Number will be a unique identifier generated by the Implantable Device – Cardiac – Reporter for each visit. + +======= 3.9.4.1.2.4 OBR Segment – Observation Request + +The ORU message may include discrete OBX segments for individual observations reported. An OBR Segment will be used for each set of such OBX segments to establish the equipment context for the observations (i.e., whether the interrogation was done in-clinic or remote). All observation dates and times reported here should match OBX segments that report the same information. + +Table 3.9.4.1.2.4-1: OBR Segment + +[width="100%",cols="18%,8%,8%,8%,7%,8%,7%,8%,8%,9%,11%",options="header",] +|=== +|Name |Seq |DT |Len |Opt |Rep |Min |Max |Tbl |Fixed Val |Ex Val +|Set ID – OBR |1 |SI |4 |O |False |0 |1 | | |1 +|Placer Order Number |2 |EI |424 |O |False |0 |1 | | | +|entity identifier |_1_ |ST |199 |O | |0 |1 | | | +|Filler Order Number |3 |EI |424 |R |False |1 |1 | | | +|_entity identifier_ |_1_ |ST |199 |O | |0 |1 | | |123456 +|Universal Service Identifier |4 |CWE |478 |R |False |1 |1 | | | +|identifier |_1_ |ST |20 |R | |1 |1 | | |Remote +|text |_2_ |ST |199 |O | |0 |1 | | | +|Observation Date/Time |7 |TS |26 |C |False |0 |1 | | | +|time |_1_ |DTM |24 |R | |1 |1 | | |20040328134623.1234+0300 +|Observation End Date/Time |8 |TS |26 |O |False |0 |1 | | | +|time |_1_ |DTM |24 |R | |1 |1 | | |20040328134623.1234+0300 +|Results Rpt/Status Chng - Date/Time |22 |TS |26 |C |False |0 |1 | | | +|Time |_1_ |DTM |24 |R | |1 |1 | | |20040328134623.1234+0300 +|Result Status |25 |ID |1 |C |False |0 |1 |0123 | |F +|=== + +Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type. + +OBR-2 Placer Order Number will usually be empty given that this is an unsolicited order. + +OBR-3 Filler Order Number will contain a unique identifier for the observation / interrogation session generated by the Implantable Device – Cardiac – Reporter. + +OBR-4.1-2 Universal Service ID, Identifier and Text can identify unique OBR segments that partition observations. The values for this field will be taken from the 11073_10103 MDC_IDC_SESS_TYPE enumerator MDC_IDC_ENUM_SESS_TYPE. + +OBR-25 Result Status values will be one of the values in Table 3.9.4.1.2.4-2. + +Table 3.9.4.1.2.4-2: Result Status + +[width="100%",cols="13%,87%",options="header",] +|=== +|Value |Description +|R |Results stored; not yet verified +|P |Preliminary: A verified early result is available, final results not yet obtained +|F |Final results: results stored and verified. Can only be changed with a corrected result. +|C |Correction to results +|=== + +======= 3.9.4.1.2.5 OBX Segments – Pulse Generator and Lead Observation Results + +Discrete OBX segments for individual observations will be encoded into separate OBX segments as individual observations or measurements. These OBX segments will be preceded by an appropriate OBR segment (see Section 3.9.4.1.2.4) to set the context for observations dealing with the implantable devices or leads. + +Table 3.9.4.1.2.5-1: OBX Segment + +[width="99%",cols="17%,7%,8%,8%,7%,8%,6%,7%,8%,10%,14%",options="header",] +|=== +|Name |Seq |DT |Len |Opt |Rep |Min |Max |Tbl |Fixed Value |Ex Val +|Set ID - OBX |1 |SI |4 |R |False |1 |1 | | |1 +|Value Type |2 |ID |3 |R |False |1 |1 |0125 | |CWE +|Observation Identifier |3 |CWE |478 |R |False |1 |1 | | | +|identifier |_1_ |ST |20 |R | |1 |1 | | |720897 +|text |_2_ |ST |199 |O | |0 |1 | | |MDC_IDC_DEV_TYPE +|name of coding system |_3_ |ID |20 |R | |1 |1 |0396 | |MDC +|Observation Sub-ID |_4_ |ST |20 |RE |False |0 |1 | | |1 +|Observation Value |_5_ |varies |99999 |RE |True |0 |* | | |ICD +|source application |1 |ST |10 |RE | |0 |1 | |Y | +|type of data | | | | | | | | | | +|Units |6 |CWE |478 |RE |False |0 |1 | | | +|identifier |_1_ |ST |20 |RE | |0 |1 | | | +|text |_2_ |ST |199 |O | |0 |1 | | | +|Abnormal Flags |8 |IS |5 |O |True |0 |* |0078 | | +|Observation Result Status |11 |ID |1 |R |False |1 |1 |0085 | | +|Date/Time of the Observation |14 |TS |26 |RE |False |0 |1 | | | +|time |_1_ |DTM |24 |RE |0 |0 |1 | | |20070422170125 +|Observation Method |17 |CWE |478 |O |True |0 |* | | | +|identifier |_1_ |ST |20 |R | |1 |1 | | | +|_text_ |_2_ |ST |199 |R | |1 |1 | | | +|Equipment Instance Identifier |18 |EI |424 |O |True |0 |* | | | +|entity identifier |_1_ |ST |199 |O | |0 |1 | | | +|=== + +Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type. + +OBX-1 Set ID – This field contains the sequence number. + +OBX-2 Value Type – The HL7 data type of the Observation Value will depend on the P11073_10103 term data type, as shown in Table 3.9.4.1.2.5-2. + +Table 3.9.4.1.2.5-2: IEEE to HL7 Data Type Matching + +[width="100%",cols="72%,28%",options="header",] +|=== +|Applicable IEEE 11073 MDC_IDC types |HL7 v2 data type +|String |ST +|Enumerated |CWE or CNE +|Date Time |DTM +|Numeric |NM +|Structured Numeric |SN (see Note) +|Encapsulated Data |ED (see Note 2) +|=== + +Note: The Structured Numeric type (SN) is used for numeric terms that require qualifications. SN types may be qualified as >Num1 or or < respectively. Alternatively, a numeric ratio between two values Num1 and Num2 may be expressed using the Separator/Suffix characters ‘/’ (solidus) or ‘:’ (either character may be used). + +Note 2: The ED data type shall be restricted to use for encapsulated PDFs and reference pointers per section 3.9.4.1.2.7 + +OBX-3.1 Observation Identifier, Identifier shall be [numeric] as defined in Annex C.3 ‘Expanded Terms’ of IEEE 11073-10103 (see 3.9.3 Referenced Standards). + +OBX-3.2 Observation Identifier, shall be as defined in Annex C.3 ‘Expanded Terms’ in IEEE 11073-10103 (see 3.9.3 Referenced Standards) + +OBX-3.3 Observation Identifier, Name of Coding System shall be MDC to reference the group of medical device communication standards (IEEE 11073-1010x) + +OBX-4 Observation Sub-ID – The sub-ID in OBX-4 shall be unique for each OBX-3 data value triplets. The combined OBX-3 and OBX-4 data values shall be unique within each message. If a value is provided in OBX-4, the value is a Sub-ID which associates the observation value with other observation values having the same Sub-ID within the same containment node within the message. If a value is provided in OBX-4 for an OBX segment containing an encapsulated PDF or reference pointer to external report, the encapsulated PDF or reference pointer to external report is assumed to be associated with a specific episode having the same Sub-ID within the message, see section 3.9.4.1.2.7 for details. An encapsulated PDF or reference pointer to external report that is not associated with an episode may be included in a message. If so, OBX-4 shall be blank. + +OBX-5 Observation Value – This is the actual value of the observation. + +If OBX-2 is of type CWE then + +OBX-5.1 shall be [numeric] as defined in Annex D.3 ‘enumerations’ or Annex E.3 ‘vendor enumerations’ of IEEE 11073-10103 (see 3.9.3 Referenced Standards) . + +OBX-5.2 shall be _ as defined in Annex D.3 ‘enumerations’ or Annex E.3 ‘vendor enumerations’ in IEEE 11073-10103 (see 3.9.3 Referenced Standards) + +OBX-5.3 shall be MDC to reference the group of medical device communication standards (IEEE 11073-1010x) + +OBX-5.9 may contain the according Display Name as defined in Annex D.3 ‘enumerations’ or Annex E.3 ‘vendor enumerations’ of IEEE 11073-10103 (see 3.9.3 Referenced Standard) or an equivalent (maybe more compact) localized display name. If the vendor has implemented vendor-specific extensions (per IEEE 11073-10103 Sections 8 and A.4) than OBX-5.9 is required. This display name should only be used by the receiving system as a reference or if the Identifier in OBX-5.1 is unknown to the receiver (e.g., for proprietary vendor content). Generation and localization of display in the receiving system shall always be preferred. + +OBX-6 Unit – Will be coded with the MDC_IDC Nomenclature (based on UCUM) Unit for associated observation. + +OBX-8 Abnormal Flags – This field will contain a code from the extended User-defined Table 0078 – Abnormal Flags as specified below. + +Table 3.9.4.1.2.5-3: User-defined Table – 078 Abnormal Flags + +[width="100%",cols="14%,16%,34%,36%",options="header",] +|=== +|Value |ExtendedValue? |Description |Comment +|NI |Yes |No information. There is no information which can be inferred from this exceptional value. |No value is provided in OBX-5. +|NAV |Yes |Temporarily not available. Information is not available at this time, but it is expected that it will be available later. |No value is provided in OBX-5. +|OFF |Yes |Numeric measurement function is available but has been deactivated by user. |No value is provided in OBX-5. +|> |N |Above absolute high-off instrument scale. |Provide the high-off instrument scale number in OBX-5 if available. +|< |N |Below absolute low-off instrument scale. |Provide the low-off instrument scale number in OBX-5 if available. +|=== + +OBX-11 Observation Result Status – This field holds the value from the table _HL7 Table 0085 - Observation result status codes interpretation._ Valid values are the following: F, P, R, S, & X. The X denotes a missing or null value, and in this case the OBX-5 will be empty. + +OBX-14 Date/Time of Observation – This field is required when the observation reported is different from the OBR report header. If an observation method is reported in OBX-17 the date will represent end date/time of the reported time interval. + +OBX-18 Equipment Instance Identifier – A unique identifier for the equipment or software that was responsible for the production of the observation + +======= 3.9.4.1.2.6 IEEE 1073.1.1.3 IDC term mapping to OBX segment + +In the IEEE 11073_10103 MDC_IDC nomenclature for Observation Identifiers (OBX-3) each term is discrete, self-descriptive and maps to one OBX segment. Refer to the IEEE 11073_10103 MDC_IDC standard for information concerning the IDC nomenclature. + +======= 3.9.4.1.2.7 OBX Segment with Encapsulated PDF or Reference Pointer to External Report [Optional] + +Optionally, observations or additional analyses may be provided in an encapsulated PDF containing displayable information or as a reference pointer to an external report. + +Table 3.9.4.1.2.7-1: OBX Segment + +[width="99%",cols="18%,7%,8%,7%,7%,8%,9%,8%,7%,9%,12%",options="header",] +|=== +|Name |Seq |DT |Len |Opt |Rep |Min |Max |Tbl |Fixed Value |Ex Val +|Set ID - OBX |1 |SI |4 |R |False |1 |1 | | | +|Value Type |2 |ID |2 |R |False | |1 |0125 |Y |ED +|Observation Identifier |3 |CWE |478 |R |False |1 |1 | | | +|identifier |_1_ |ST |20 |R | |1 |1 | |Y |18750-0    +|Text |2 |ST |199 |R | |1 |1 | |Y |Cardiac Electrophysiology Report +|_name of coding system_ |_3_ |ID |20 |R | |0 |1 |0396 |Y |LN +|alternate identifier |4 |ST |255 |RE | |0 |1 | | |file_name_example.pdf +|alternate text |5 |ST |100 |RE | |0 |1 | | |Example Cardiac Device Report +|Observation Sub-ID |4 |ST |20 |RE |False |0 |1 | | |1 +|Observation Value |5 |ED |99999 |R |True |1 |* | | |Encapsulated PDF +|source application |_1_ |ST |10 |RE | |0 |1 | |Y |Application +|type of data |_2_ |ST |10 |RE | |0 |1 | |Y |PDF +|Encoding |_4_ |ST |10 |RE | |0 |1 | |Y |Base64 +|Data |_5_ |ED |* |RE | |0 |1 | |Y |Encapsulated and Base64 binary encoded PDF File +|Observation Result Status |11 |ID |1 |R |False |1 |1 |0085 | | +|Date/Time of the Observation |14 |TS |26 |RE |False |0 |1 | | | +|Time |_1_ |DTM |24 |R | |1 |1 | | |20040328134623.1234+0300 +|=== + +Note: Field names are in Roman type, relevant component names within a field are listed underneath in italic type. + +OBX-2 If sending an encapsulated PDF, the value will be ED. If referencing an external report, the value will be RP. + +OBX-3 This field contains the coding system identifier (LOINC) and further information about the file name and content. + +OBX-3.1 - 3.3 - Value is a report ID from the LOINC coding system, and will be set to 18750-0^Cardiac Electrophysiology Report^LN. + +OBX-3.4 This field can be used to include a file name. Include the full file name with extension as applicable. Special characters shall not be used. + +OBX-3.5 This field can be used to include a document title which can be used for display purposes. The document title shall be in the language specified in MSH-19 within the message. + +OBX-4 If a value is provided here the embedded PDF will contain data related to a specific episode or EGM being referenced via grouping to other episode related data elements having the same Sub-ID in OBX-4 inside this message. An encapsulated PDF or reference pointer to external report that is not associated with an episode may be included in a message. If so, OBX-4 shall be blank. + +OBX-5 If referencing an external document, the Observation Value will contain a reference pointer to the external document. + +OBX-5.1 If sending an encapsulated PDF, the Type of Data component will have the value "Application" + +OBX-5.2 If sending an encapsulated PDF, the Data Subtype component will have the value "PDF". + +OBX-5.3 Will be empty + +OBX-5.4 If sending an encapsulated PDF, the Encoding component will have the value "Base64". + +OBX-5.5 If sending an encapsulated PDF, the Data component contains the encapsulated Base64-encoded PDF/A document in accordance with ISO 19005-1. + +Notes: 1. An actor participating in this transaction must support encapsulated data with a length beyond the nominal 65536 byte limit of the OBX-5. + +{empty}2. The base64 encoded stream must not include CR/LF characters, which are forbidden within HL7 field text streams. Breaking a base64 encoded stream into lines of 76 characters or less is used for email in accordance with RFC822, but is not applicable to encapsulated data in HL7. + +The attached PDF or externally referenced report will contain in its content the device ID, patient ID and name if known, and the dates of the procedure and document. + +======= 3.9.4.1.2.8 NTE Segment – Notes and Comments [Optional] + +Table 3.9.4.1.2.8-1: NTE Segment – Notes and Comments + +[width="100%",cols="18%,8%,10%,6%,8%,11%,10%,9%,9%,11%",options="header",] +|=== +|ELEMENT NAME |SEQ |COMP |DT |LEN |USAGE |CARD |TBL# |Fixed |Ex. Values +|Set ID - NTE |1 | |SI |4 |O |[0..1] | | |1 +|Source of comment |2 | |CX |20 |O |[0..1] | |Y |L +|Comment |3 | |FT |65536 |O |[0..*] | | | +|=== + +NTE-3 Comments – Contains any notes, comments needed that are not included as part of an observation. + +====== 3.9.4.1.3 Expected Actions + +======= 3.9.4.1.3.1 Implantable Device – Cardiac – Consumer + +The Implantable Device – Cardiac – Consumer will return the standard HL7 acknowledgement message to the Device Observation Creator. + +==== Security Considerations + +This profile does not require the use of ATNA. There are several implementation models for this profile that do not require transmission of data over public networks including intra-institutional, VPN, etc. However, when public networks are used, ATNA is one option for secure transport over those networks. It is recommended that the Implantable Device – Cardiac – Reporter be grouped with the Secure Node of the ATNA Profile to secure communications for remote follow-ups if data is sent across an un-trusted network. + +=== 3.10 Communicate Infusion Event Data [PCD-10] + +This section corresponds to the Communicate Infusion Event Data (PCD-10) transaction of the IHE Devices Technical Framework. Communicate Infusion Event Data is used by the DOR and DOC Actors. + +==== 3.10.1 Scope + +This transaction is used to communicate infusion event data from: + +* A Device Observation Reporter (DOR) to a Device Observation Consumer (DOC). + +==== 3.10.2 Use Case Roles + +*Actor:* Device Observation Reporter + +*Role:* Sends infusion event data to DOC + +*Actor:* Device Observation Consumer + +*Role:* Receives infusion event data from DOR + +==== 3.10.3 Referenced Standard + +* HL7® - Health Level 7 Version 2.6 Ch7 Observation Reporting +* ISO/IEEE 11073-10101 Nomenclature +* IEEE P11073-10101a Nomenclature + +==== + +3.10.4 Messages + +===== 3.10.4.1 Communicate Infusion Event Data + +Event messages are generated by the infusion pump or Gateway during normal execution of an infusion therapy. Example of such events are start of infusion delivery, rate change or transition from piggyback to primary or transition to KVO. This information is sent from a DOR to a DOC. + +Note that while a system is off-line, all events should be buffered and then communicated when communication is established again. Event time stamps should indicate when the event occurred, not when it was communicated. + +====== 3.10.4.1.1 Trigger Events + +The ORU^R42^ORU_R01 message is an unsolicited update initiated by the Device Observation Reporter. The ORU^R42 can be sent with or without a preceding order, since it is common in a clinical setting for device data to be reported without a specific order having been transacted in the information system (that is, the reporting is the result of a "standing order" for monitoring in a particular clinical situation). + +====== 3.10.4.1.2 Message Semantics + +Refer to the HL7^®^ standard for the ORU message of HL7 2.6 Chapter 7 and the general message semantics. + +The ORU^R42^ORU_R01 message structure provides the mechanism for mapping the hierarchical structure of an IEEE 11073 containment tree to a series of OBX segments. See the discussion of how the containment is represented using a "dotted notation" in field OBX-4 Observation Sub-ID in the DEV TF-2: Appendix B.8. + +See “ISO/IEEE Nomenclature mapping to HL7 OBX-3” in the DEV TF-2: Appendix A.1 for further information on the mapping rules. + +====== 3.10.4.1.3 Expected Actions + +The ORU^R42^ORU_R01 message is sent from the DOR to the DOC. Upon receipt the DOC validates the message and responds with an acknowledgement as defined in DEV TF-2: Appendix G.1, Acknowledgment Modes. + +[#_Toc181625213 .anchor]####Appendices + +== Appendix A Mapping ISO/IEEE 11073 Domain Information Model to HL7 + +Figure A-1: System Package Model represents the system level containment of the 11073 DIM. + +image:extracted-media-tf2/media/image35.png[extracted-media-tf2/media/image35,width=572,height=459] + +Figure A-1: System Package Model + +The mapping from 11073 to HL7 will be described by focusing on the Medical Package defined by the Medical Device System shown in Figure A-1: System Package Model and elaborated in Figure A-2: Medical Package Model. + +image:extracted-media-tf2/media/image36.png[extracted-media-tf2/media/image36,width=596,height=450] + +Figure A-2: Medical Package Model + +The HL7 OBX segment provides two fields which are used in mapping the objects shown in Figure A-2: Medical Package Model; these are OBX-3 Observation Identifier and OBX-4 Observation Sub-Id. + +OBX-3 is expressed as an HL7 Coded Element With Exceptions (CWE) data type and the details of mapping the 11073 MDC to the HL7 CWE datatype are described in Appendix A.1 ISO/IEEE Nomenclature mapping to HL7 OBX-3. + +OBX-4 is used to express the containment level of a particular item expressed in OBX-3. This is done by defining the nodes of the hierarchy of the containment tree as a set of ordinal numbers expressed in a dotted notation such that each OBX-3 is expressed unambiguously in terms of its containment as defined by OBX-4. This may be supplemented by a further level or levels to distinguish attributes or other subordinate structures as may be specified in particular PCD profiles. See under OBX-4 in Appendix B for the details of the "dotted notation" used to express this containment. + +image:extracted-media-tf2/media/image37.png[extracted-media-tf2/media/image37,width=496,height=349] + +Figure A-3: Example of Mapping Containment to OBX-4 + +For example, the OBX-4 for the
would be expressed as 1.2.1.3. + +NOTE: The ordinal numbers in an OBX-4 are not normative for a given parameter (identified in OBX-3) and may vary between implementations. Each OBX-4 Sub-Id must be unique within a given containment and message, but the numbers and mappings may change between messages. + +In OBX-2 the valid HL7 types for the mapping are NM, ST, SN, CWE, CF (String may have some implied structure) + +The specification of the containment tree provides a mechanism to address dynamic configuration of a PCD. For example, a patient monitor may have one or more "plug-ins" which may be added to and removed from the patient monitor as the patient’s clinical condition changes. These should be individually identifiable by a unique device instance identifier. When a plug-in is removed, the ordinal numbers previously assigned to that plug-in should be reserved. Addition of a new plug-in with a different unique device instance identifier shall result in the assignment of ordinal numbers which have not been reserved. Replacement of the "known" plug-in after its removal shall result in the re-assignment of the same reserved ordinal number to the plug-in that it formerly had. If the DOR system cannot distinguish individual instances of a module, it may treat modules that are functionally equivalent as though they were the same module for the purposes of the above scheme. + +=== A.1 ISO/IEEE Nomenclature mapping to HL7 OBX-3 + +The ISO/IEEE Nomenclature provides an unambiguous coding which is mapped to HL7 OBX-3 as follows: + +HL7 OBX-3 is of type CWE consisting of: + +Table A.1-1: HL7 Component Table - CWE - Coded With Exceptions + +[width="100%",cols="11%,9%,6%,10%,9%,9%,15%,15%,16%",options="header",] +|=== +|SEQ |LEN |DT |Usage |Card. |TBL# |Component Name |Comments |Sec Ref +|1 |20 |ST |R |[1..1] | |Identifier |Nomenclature Code |2.A.74 +|2 |199 |ST |R |[1..1] | |Text |Reference ID |2.A.74 +|3 |20 |ID |R |[1..1] |0396 |Name of Coding System |"MDC" |2.A.35 +|4 |20 |ST |RE |[0..1] | |Alternate Identifier | |2.A.74 +|5 |199 |ST |RE |[0..1] | |Alternate Text | |2.A.74 +|6 |20 |ID |RE |[0..1] |0396 |Name of Alternate Coding System | |2.A.35 +|7 |10 |ST |X |[0..0] | |Coding System Version ID | |2.A.74 +|8 |10 |ST |X |[0..0] | |Alternate Coding System Version ID | |2.A.74 +|9 |199 |ST |X |[0..0] | |Original Text | |2.A.74 +|=== + +Definition: This data type transmits codes, and the text associated with the code. + +[width="100%",cols="100%",options="header",] +|=== +|Maximum Length: 705 +|=== + +Where: + +Nomenclature Code is the string representation of the decimal value corresponding to the context free 32bit representation of the Nomenclature Code + +[context-free] Nomenclature Code = (Code Block number * 2**16) + [context-sensitive], where [context-sensitive] is an offset, reflecting a particular variant of an associated "discriminator". The Reference ID is also modified to reflect the variant. + +For example, for the "Device Type" Nomenclature, the Device Type discriminator is as follows: + +[width="100%",cols="36%,32%,32%",options="header",] +|=== +|Ref ID variant |Description |Term Code Offset +|DEV |Not otherwise specified |0 +|MDS |Medical Device System |1 +|VMD |Virtual Medical Device |2 +|CHAN |Channel |3 +|=== + +Nomenclature codes are obtained from IEEE-11073-10101 Medical Device Communications – Nomenclature where available. Additional codes that are not yet standardized are contained in the Rosetta Terminology Mapping (see IHE Devices Technical Framework Volume 3). + +The context-free nomenclature code for a term in code block number 1 whose term code=4104 is equal to ((1 * 2**16) + 4104) = 1*65536 + 4104 = 69640 (which uniquely identifies the SpO2 monitor term) with a Reference ID of MDC_DEV_ANALY_SAT_O2. The context-sensitive form for the variant "MDS” is “MDC_DEV_ANALY_SAT_O2_MDS (appending the suffix "MDS"), and the Term Code is 69640+1 = 69641 (adding the Term Code Offset to the base Term Code). + +The OBX-3 representation is “69641^MDC_DEV_ANALY_SAT_O2_MDS^MDC" + +The Virtual Medical Device variants are: MDC_DEV_ANALY_SAT_O2_VMD 69642, and "69642^ MDC_DEV_ANALY_SAT_O2_VMD^MDC" in OBX-3 representation. + +To distinguish between periodic and aperiodic data, map from the IEEE 11073 Metric Access to HL7 and code in OBX-17. This is used where you want to distinguish periodic, aperiodic etc. Metric Category also provides a distinction between manual and automatic. + +Examples of device data (as opposed to patient data) that may be included to allow a receiving system to have a better record of the nature and status of a device are: + +MDC_ATTR_SYS_TYPE is used to describe the type of device such as monitor, ventilator, infusion pump, and shall be mapped at the MDS level in the OBX with the value described by OBX-3. + +MDC_ATTR_ID_MODEL is used to provide device vendor/model and shall be mapped at the MDS level in the OBX with the value described by OBX-3. + +The unique identification of the particular instance of the device is put in OBX-18. + +MDC_ATTR_VMS_MDS_STAT describes states - disconnected, configuring, operating, terminating, disassociated, reconfiguring. + +For PCDs with complex operation states such as an infusion pump with a set of states like "Stopped", "Infusing Primary", "Infusing Secondary", "Bolus", etc., or a ventilator with states "Standby", "Ventilating", etc., the Device Operational Status Enumeration Object is mapped to OBX-3. + +See the Rosetta Terminology Mapping documents referenced in IHE Devices Technical Framework Vol. 3 for further examples of device data. + +== Appendix B Common Segment Descriptions + +=== B.1 MSH – Message Header Segment + +See HL7 v2.6: chapter 2 (2.14.9) + +This segment defines the intent, source, destination, and some specifics of the syntax of a message. + +Table B.1-1: MSH - Message Header + +[width="100%",cols="13%,13%,8%,10%,10%,11%,35%",options="header",] +|=== +|SEQ |LEN |DT |Usage |Card. |TBL# |Element name +|1 |1 |ST |R |[1..1] | |Field Separator +|2 |4 |ST |R |[1..1] | |Encoding Characters +|3 |227 |HD |R |[1..1] |0361 |Sending Application +|4 |227 |HD |RE |[0..1] |0362 |Sending Facility +|5 |227 |HD |RE |[0..1] |0361 |Receiving Application +|6 |227 |HD |RE |[0..1] |0362 |Receiving Facility +|7 |24 |DTM |R |[1..1] | |Date/Time of Message +|8 |40 |ST |X |[0..0] | |Security +|9 |15 |MSG |R |[1..1] | |Message Type +|10 |199 |ST |R |[1..1] | |Message Control Id +|11 |3 |PT |R |[1..1] | |Processing Id +|12 |60 |VID |R |[1..1] | |Version ID +|13 |15 |NM |RE |[0..1] | |Sequence Number +|14 |180 |ST |X |[0..0] | |Continuation Pointer +|15 |2 |ID |R |[1..1] |0155 |Accept Acknowledgement Type +|16 |2 |ID |R |[1..1] |0155 |Application Acknowledgement Type +|17 |3 |ID |RE |[0..1] |0399 |Country Code +|18 |16 |ID |RE |[0..1] |0211 |Character Set +|19 |705 |CWE |RE |[0..1] | |Principal Language of Message +|20 |20 |ID |X |[0..0] |0356 |Alternate Character Set Handling Scheme +|21 |427 |EI |O |[0..1] | |Message Profile Identifier +|22 |567 |XON |X |[0..0] | |Sending Responsible Organization +|23 |567 |XON |X |[0..0] | |Receiving Responsible Organization +|24 |227 |HD |X |[0..0] | |Sending Network Address +|25 |227 |HD |X |[0..0] | |Receiving Network Address +|=== + +MSH-1 Field Separator + +The IHE Devices Technical Framework requires that applications support HL7-recommended value that is | (ASCII 124). + +MSH-2 Encoding Characters + +This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. The IHE Devices Technical Framework requires that applications support HL7-recommended values ^~\& (ASCII 94, 126, 92, and 38, respectively). + +MSH-3 Sending Application (HD) + +Components: ^ ^ + +The intention of this field is to uniquely identify the software application implementing the PCD actor sending this message. For valid methods of accomplishing this, see Hierarchic Designator (HD) Data Type, Appendix Section C.6. + +MSH-4 Sending Facility + +Components: ^ ^ + +For the IHE Devices Technical Framework, when populated, this field shall be implemented as: + +First component (required): Namespace ID. The name of the organizational entity responsible for the DOR, typically the provider institution or department operating the DOR. + +Second component (optional): The Universal ID (see HL7 v. 2.7 Ch. 2) of the organizational entity responsible for the DOR. + +Third component (optional): The Universal ID Type. The codification of these three components is entirely site-defined. It may be detailed in the national extensions of this framework. + +MSH-5 Receiving Application (HD) + +Components: ^ ^ + +For the IHE Devices Technical Framework, when populated, this field shall be implemented as: + +First component (required): Namespace ID. The name of the organizational entity responsible for the receiving application. + +Second component (optional): The Universal ID (see HL7 v. 2.7 Ch. 2) of the organizational entity responsible for the receiving application. + +Third component (optional): The Universal ID Type. The codification of these three components is entirely site-defined. It may be detailed in the national extensions of this framework. + +This field is not required for IHE PCD compliance but should be populated at the option of the organization operating the system if the field serves a desired function, such as facilitating the routing of messages. + +MSH-6 Receiving Facility + +Components: ^ ^ + +For the IHE Devices Technical Framework, when populated, this field shall be implemented as: + +First component (required): Namespace ID. The name of the organizational entity responsible for the receiving facility. + +Second component (optional): The Universal ID (see HL7 v. 2.7 Ch. 2) of the organizational entity responsible for the receiving facility. + +Third component (optional): The Universal ID Type. The codification of these three components is entirely site-defined. It may be detailed in the national extensions of this framework. + +MSH-7 Date/Time of Message: + +The IHE DEV TF requires this field be populated with: + +Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ] + +Time zone qualification of the date/time is required. The IHE DEV TF uses the IETF RFC3339 “Unknown Local Offset Convention” to make it possible to distinguish between the case where UTC is the preferred reference point for the specified, denoted with +0000, and the case where the UTC time is known, but the offset to local time is unknown, denoted with -0000. This distinction is sometimes important in devices. + +MSH-7 shall be used only to provide time a message is created by the sending system, which is different from, and not be interpreted as, the time an observation is taken. See Section B.8.7 Time Stamps and Time Synchronization for a discussion of general considerations on time stamps in IHE PCD messages. + +MSH-9 Message Type + +Components: ^ ^ + +Definition: This field contains the message type, trigger event, and the message structure ID for the message. All three components are required. + +Its content is defined within each transaction-specific section of this document. + +For [PCD-01], this field must contain ORU^R01^ORU_R01. + +The PCD PIV Profile requires that this field be valued as follows: + +* RGV^O15^RGV_O15 for the IOP to IOC message that initiates the [PCD-03] transaction +* ACK^O15^ACK for the IOC to IOP accept acknowledgment message +* RRG^O16^RRG_O16 for the IOC to IOP application acknowledgment message +* ACK^O16^ACK for the IOP to IOC acknowledgment of the IOC to IOP application acknowledgment message +* For [PCD-04], this field must contain ORU^R40^ORU_R40. +* For [PCD-05], this field must contain ORU^R41^ORU_R41. + +MSH-10 Message Control Id + +Definition: This field contains a number or other identifier that uniquely identifies the message. Each message should be given a unique identifier by the sending system. The receiving system shall echo this ID back to the sending system in the Message Acknowledgment segment (MSA). The combination of this identifier and the name of the sending application (MSH-3) shall be unique across the Healthcare Enterprise. + +MSH-11 Processing ID: + +Components: ^ + +Definition: This data type indicates whether to process a message as defined in HL7 Application (level 7) processing rules. + +The IHE Devices Technical Framework requires the first component Processing ID be valued based on HL7 Table 0103. Use of the second component Processing Mode is optional but if used is based on HL7 Table 0207. + +The value in production systems should be P (Production). When it is desired to recognize and isolate test data, the value D (Debugging) may be used. + +MSH-12 Version ID + +Components: ^ ^ + +Definition: This field is matched by the receiving system to its own version to be sure the message will be interpreted correctly. + +The DEV TF is based on HL7 V2.6. Where specific elements of later versions are required, they have been used and their usage flagged. + +Although HL7 allows international affiliate versions to be specified the IHE Devices Technical Framework uses only the core version (first component of the field). + +MSH-13 Sequence Number (ID), required but may be empty: + +Definition: A non-null value in this field implies that the sequence number protocol is in use. The sequence number protocol is not used in IHE PCD. + +MSH-15 Accept Acknowledgement Type + +Definition: This field identifies the conditions under which accept acknowledgments are required to be returned in response to this message. Required. Refer to HL7 Table 0155 - Accept/application acknowledgment conditions for valid values. The receiving system must send (or not send) acknowledgements as specified by this field. + +In [PCD-01], [PCD-04], and [PCD-05] transactions, this field shall be valued as AL. + +In [PCD-03] transactions, see Section 3.3.4.4.1 + +MSH-16 Application Acknowledgement Type + +Definition: This field identifies the conditions under which application acknowledgments are required to be returned in response to this message. Required for enhanced acknowledgment mode. Refer to HL7 Table 0155 - Accept/application acknowledgment conditions for valid values. For [PCD-01] and [PCD-05] transactions this field shall be valued as NE. The ACM AR Actor should use MSH-16 in [PCD-04] to indicate whether or not the AR Actor is prepared to receive [PCD-05] transactions. Set MSH-16 of the [PCD-04] transaction to other than NE to receive [PCD-05] transaction (and other error indications) or set it to NE to indicate to the AM Actor that [PCD-05] transactions are not to be sent. The receiving system must send (or not send) acknowledgements as specified by this field. + +For [PCD-03] transactions, see Section 3.3.4.4.1 + +MSH-17 Country Code + +Definition: This field contains the country of origin for the message. It will be used primarily to specify default elements, such as currency denominations. The values to be used are those of ISO 3166. The ISO 3166 table has three separate forms of the country code: HL7 specifies that the 3-character (alphabetic) form be used for the country code. + +MSH-18 Character Set (ID) + +Definition: This field contains the character set for the entire message. Refer to HL7 Table 0211 - Alternate character sets for valid values. + +An HL7 message uses field MSH-18-character set to specify the character set(s) in use. Valid values for this field are specified in HL7 Table 0211, "Alternate Character Sets". MSH-18-character set may be left blank or may contain a single value. If the field is left blank, the character set in use is understood to be the 7-bit ASCII set, decimal 0 through decimal 127 (hex 00 through hex 7F). This default value may also be explicitly specified as ASCII. + +Any encoding system, single-byte or multi-byte may be specified as the default character encoding in MSH-18-character set. If the default encoding is other than 7-bit ASCII, sites shall document this usage in the dynamic conformance profile or other implementation agreement. This is particularly effective in promoting interoperability between nations belonging to different HL7 Affiliates, while limiting the amount of testing required to determine the encoding of a message. + +See HL7 V2.6 for the semantics for alphabetic languages other than English (2.15.9.18.1) and for non-alphabetic languages (2.15.9.18.2) + +The DEV TF requires this field to be valued if the character set is other than ASCII. If the character set is ASCII the field may be null or have the value of ASCII. A single character set is required for a given message. + +MSH-19 Principal Language of Message + +Components: ^ ^ ^ ^ ^ + +Definition: This field contains the principal language of the message. Codes come from ISO 639. + +The PCD uses a default of en^English^ISO639 if the field is empty. + +MSH-21 Message Profile Identifier + +Components: ^ ^ ^ + +For DEV TF, this field is required in non-ACK messages to allow identification of a specific message profile, particularly for testing purposes (it is superfluous and therefore not required in ACK messages). PCD message profiles are assigned ISO OIDs by the Devices Technical Committee and the appropriate Message Profile Identifiers are to be used here in conformant messages. When multiple message profiles are listed in this field they should be (vendor specific, country specific) constraints of the PCD profile. Note that the overriding of PCD profile constraints is only allowed in national extensions to this framework. + +Assigned OIDs for PCD messages (note that for convenience of reference this table includes OIDs for some messages that are not yet in Final Text status and are therefore not described in this Final Text Technical Framework document): + +[width="100%",cols="31%,69%",options="header",] +|=== +|Assigned OID |PCD Message +|1.3.6.1.4.1.19376.1.6.1.1.1 |Device to Enterprise Communications PCD-01 Communicate PCD Data message (also used for observations in response to a PCD-02 PCD Data Query) +|1.3.6.1.4.1.19376.1.6.1.2.1 |Device to Enterprise Communications PCD-02 PCD Data Query +|1.3.6.1.4.1.19376.1.6.1.3.1 |Point-of-care Infusion Verification PCD-03 Communicate Infusion Order message +|1.3.6.1.4.1.19376.1.6.1.3.2 |Point-of-care Infusion Verification RRG^O16^RRG_O16 Pharmacy/Treatment Give Acknowledgment Message +|1.3.6.1.4.1.19376.1.6.1.9.1 |Implantable Device - Cardiac Communicate IDC Observations +|1.3.6.1.4.1.19376.1.6.1.4.1 |Alert Communication Management PCD-04 Report Alert message +|1.3.6.1.4.1.19376.1.6.1.5.1 |Alert Communication Management PCD-05 Report Alert Status message +|1.3.6.1.4.1.19376.1.6.1.6.1 |Alert Communication Management PCD-06 Disseminate Alert +|1.3.6.1.4.1.19376.1.6.1.7.1 |Alert Communication Management PCD-07 Report Alert Dissemination Status +|=== + +The ISO OID in the table should be used as the universal ID (EI-3). The Universal ID Type (EI-4) for ISO OIDs is “ISO”. In IHE PCD profiles, the Entity Identifier (EI-1) is optional and may contain a human-readable name for the profile in the form “IHE_PCD_XXX” where XXX identifies the IHE PCD transaction, for example, IHE_PCD_001 for [PCD-01]. Namespace Identifier (EI-2) is also optional, but may contain “IHE PCD” to identify the source of the profile for a human reader. It is emphasized that these suggested values are only for human readability and shall play no role in processing. Processing which depends on the Message profile identifier in the receiving application or in a test system shall base its recognition of the profile solely on the ISO OID (Universal ID, EI-3). + +Example: IHE_PCD_001^IHE PCD^1.3.6.1.4.1.19376.1.6.4.4.1^ISO + +=== B.2 MSA – Message Acknowledgement Segment + +See HL7 v2.6: chapter 2 (2.14.8) + +This segment contains information sent while acknowledging another message. + +Table B.2-1: MSA - Message Acknowledgement + +[width="100%",cols="14%,9%,9%,12%,10%,12%,34%",options="header",] +|=== +|SEQ |LEN |DT |Usage |Card. |TBL# |Element name +|1 |2 |ID |R |[1..1] |0008 |Acknowledgement code +|2 |20 |ST |R |[1..1] | |Message Control Id +|3 |80 |ST |X |[0..0] | |Text Message +|5 |1 |ID |X |[0..0] | |Delayed Acknowledgment Type +|6 |705 |CWE |X |[0..0] |0357 |Error Condition +|=== + +*MSA-1 Acknowledgment Code* + +This field indicates the result of the processing of the message it is acknowledging. + +Table B.2-2: HL7 table 0008 - Acknowledgement code + +[width="100%",cols="13%,43%,44%",options="header",] +|=== +|Value |Description |Comment +|CA |Enhanced mode: Accept acknowledgment: Commit Accept |The message has been reviewed and accepted. +|CE |Enhanced mode: Accept acknowledgment: Error |The message has been rejected for an error. +|CR |Enhanced mode: Accept acknowledgment: Commit Reject |The message has been rejected by the receiving system +|AA |Original mode Application Acknowledgment:Accept. Enhanced mode: Application acknowledgement: Accept |The receiving system accepted and integrated the message. +|AR |Original mode Application Acknowledgment:Reject. Enhanced mode: Application acknowledgement: Reject |The receiving system rejected the message +|AE |Original mode Application Acknowledgment: Error. Enhanced mode: Application acknowledgement: Error |The receiving system rejected the message for an error. +|=== + +MSA-2 Message Control ID + +Definition: This field contains the message control ID from the MSH-10 - Message Control ID of the incoming message for which the acknowledgement is sent. + +MSA-3 Text Message + +See the ERR segment. + +=== B.3 ERR – Error Segment + +HL7 v2.6, Chapter 2 (2.14.5) + +This segment is used to add error comments to acknowledgment messages. + +Table B.3-1: ERR - Error segment + +[width="100%",cols="11%,9%,11%,14%,12%,14%,29%",options="header",] +|=== +|SEQ |LEN |DT |Usage |Card. |TBL# |Element name +|1 |493 |ELD |B |[0..1] | |Error Code and Location +|3 |705 |CWE |R |[1..1] |0357 |HL7 Error Code +|4 |2 |ID |R |[1..1] |0516 |Severity +|5 |705 |CWE |RE |[0..1] |0533 |Application Error Code +|6 |80 |ST |C |0..1 | |Application Error Parameter +|=== + +Notes: ERR-1 is included in HL7 v2.6 for backward compatibility only. Within the context of IHE PCD, this field shall not be used. + +ERR-3 and ERR-4 are required by HL7 v2.6 + +*Use of Error Segment in the PIV Profile.* This list of error codes that can occur during the processing of a PCD-03 message is consolidated from participating pump vendors. The application acknowledgment from the IOC should contain the Code and Text in ERR-5.1 and ERR-5.2 respectively. ERR-5.9 can also be used to contain additional text related to the error. + +Note that there should be no expectation that each pump vendor or pump model will support all of the codes in this list. + +[width="100%",cols="15%,42%,43%",options="header",] +|=== +|Code |Text |Example +|9001 |Unknown infuser or channel |e.g., incorrect infuser or channel ID +|9002 |Infuser/channel is currently infusing | +|9003 |Missing required program parameter(s) (ParameterName1, ParameterName2, ...) |e.g., Give Amount Minimum (RXG-5) - volume to be infused - is missing +|9004 |Invalid program parameter(s) (ParameterName1, ParameterName2, ...) |e.g., volume units are not mL +|9005 |Parameter (ParameterName) outside of allowable range (MinValue to MaxValue) |e.g., ordered rate greater than pump maximum +|9006 |Infuser is powered off | +|9007 |Infuser is offline or unable to connect to infuser |e.g., infuser not on network or weak wireless signal +|9008 |Invalid units for parameter (ParameterName) |e.g., Give Strength Volume Units (RXG-24) contains a medication unit value instead of volume units +|9009 |Dose/Rate Units do not match drug library |e.g., ordered units = mL/hr; drug library units =mcg/kg/min +|9010 |Unable to match medication to drug library |e.g., Medication does not exist in drug library +|9011 |Patient weight mismatch |e.g., patient weight known by pump differs from weight sent in [PCD-03] +|9012 |Patient ID mismatch |e.g., patient ID known by pump differs from ID sent in [PCD-03] +|9013 |Unable to program medication as piggyback |e.g., medication not configured for piggyback administration in drug library +|9014 |Dose rate or VTBI exceeds maximum |e.g., greater than pump maximum +|9015 |Request timed out | +|9016 |Other error |Used when other errors are not applicable +|9017 |Infuser cannot accept program |Infuser is in a state where it cannot accept program; e.g., alarming or in standby +|9018 |Parameter (ParameterName) does not match drug library    |e.g., Give Strength Units (RXG-18) = mg, drug library = mEq +|9019 |Patient weight missing |Drug is weight-based or BSA-based, but patient weight OBX is missing +|9020 |Patient height missing |Drug is BSA-based, but patient height OBX is missing  +|9021 |Care area or profile mismatch |Care area or profile not cleared on pump; or pump is set to a different care area +|9022 |Requested infusion program is stale |The value of ORC.9 is older than what the IOC will allow to program the pump +|9023 |Program rejected by user |Program rejected by user prior to starting infusion +|9024 |Drug library hard limit exceeded |e.g., dose exceeds maximum allowable for medication +|9025 |Lockout interval missing |Lockout Interval is required when Patient Dose is present +|9026 |Dose limit missing |PCA dose limit is required but missing +|9027 |Patient BSA missing |Drug is BSA-based but BSA OBX is missing +|9028 |Tubing, cassette, or syringe not installed on pump |Used when required by pump +|9029 |Care area or profile not selected |Used when required by pump +|9030 |Current medication cannot be interrupted |Medication on primary cannot be interrupted by a piggyback +|9031 |Patient ID missing or invalid | +|9032 |Pump is in delayed start | +|9033 |Pump is alarming | +|9034 |Not enough fluid or medication in container to deliver bolus |Applies to bolus from existing infusion only +|9035 |Parent order ID does not match the currently programmed order |Applies to bolus from existing infusion only +|9036 |Medication does not match the currently programmed order |Applies to bolus from existing infusion only +|9037 |Medication concentration does not match the currently programmed order |Applies to bolus from existing infusion only +|9038 |Bolus order type is not supported |ORC-1 = “CH” not supported by pump +|9039 |Medication does not support bolus |Medication in drug library not configured for bolus +|9040 |Bolus dose units do not match the currently programmed order |e.g., “mg” instead of “mL” +|9041 |Unable to parse multistep program |Applies to multistep infusion only +|9042 |Medication is not configured for loading dose |Applies to multistep infusion only +|9043 |Medication does not support multistep |Applies to multistep infusion only +|9044 |Multistep order type is not supported |Applies to multistep infusion only +|=== + +ERR-5 Application Error Code + +Application specific codes for infusion-related errors resulting from a [PCD-03] transaction, identifying the specific error that occurred, are given in the IHE PCD Application Error Table. New codes may be added from time to time through the IHE Change Proposal Process. The IHE PCD website should be consulted for the latest approved table (http://wiki.ihe.net/index.php?title=PumpErrorCodes[[.underline]#http://wiki.ihe.net/index.php?title=PumpErrorCodes#]). + +ERR-6 Application Error Parameter + +Additional information to be used with application specific codes calling for the input of Parameter names or values as called for in the IHE PCD Application Error Table. + +=== B.4 NTE - Notes and Comment Segment + +HL7 v2.6 : chapter 2 (2.4.10) + +This segment is used for sending notes and comments. + +The IHE Devices Technical Framework limits the use of this segment to only one purpose: to comment the observations and the orders. Therefore, in the messages of this Integration Profile, NTE segments appear only following either OBR or OBX segments. + +Information that can be coded in OBX segments or OBR segments shall not be sent in a NTE segment. + +Detail of the fields used by the NTE segment in the PCD Observation Message is given below. + +Table B.4-1: NTE - Notes and Comment segment + +[width="100%",cols="14%,10%,8%,10%,12%,10%,36%",options="header",] +|=== +|SEQ |LEN |DT |Usage |Card. |TBL# |Element name +|1 |4 |SI |R |[1..1] | |Set ID – NTE +|2 |8 |ID |X |[0..0] | |Source of Comment +|3 |65536 |FT |RE |[0..1] | |Comment +|4 |705 |CWE |X |[0..0] | |Comment Type +|5 |3220 |XCN |X |[0..0] | |Entered by +|6 |24 |DTM |X |[0..0] | |Entered Date/Time +|7 |24 |DTM |X |[0..0] | |Expiration Date +|=== + +NTE-1 Set ID + +This field may be used where multiple NTE segments are used in a message. Their numbering must be described in the application message definition. + +NTE-3 Comment + +This field contains the text of the comment. This text may be formatted. In order to delete an existing comment, the field shall contain empty quotation marks: "“. + +Comment text of identical type and source shall be included in the same occurrence of an NTE segment, and not be split over multiple segments. + +*NTE Notes and Comment Segment in PCD-04 Message* + +By site-specific agreement between implementers of the Alert Reporter and Alert Manager Actors, additional information not provided for in other segments may be included in the NTE Notes and Comment segments. Site or system specific indications are optionally passed in this manner to the Alert Manager for us by its message dispatching logic, or to pass additional information through the Alert Manager to the Alert Communicator to communications endpoints. + +Optional ad-hoc annotation text to be included in the alert notification text message sent from the ACM Alert Manager to the ACM Alert Communicator is to be included in an occurrence of an NTE segment in association with the OBX segment which identifies the alert indication. This text doesn’t replace any alert notification text synthesized by the ACM AM from alert data provided to the ACM Alert Manager by the Report Alert PCD-04 message. + +Table B.4-2: HL7 Attribute Table – NTE – Notes and Comment + +[width="100%",cols="12%,10%,8%,9%,9%,10%,42%",options="header",] +|=== +|SEQ |LEN |DT |OPT |RP/# |TBL# |ELEMENT NAME +|3 |65536 |FT |O |Y | |Comment +|=== + +*NTE-3 Comment (FT)* + +This field contains the comment conveyed by the segment. + +=== B.5 PID - Patient Identification segment + +HL7 v2.6: chapter 3 (3.4.2) + +The PID segment is used by all applications as the primary means of communicating patient identification information. This segment contains permanent patient identifying and demographic information that, for the most part, is not likely to change frequently. + +Patient Care Devices or gateway systems providing PCD observation reports are not ordinarily primary interfaces for detailed patient demographic information. Another information system such as a master patient index will generally be the source of authoritative information sent in the PID segment. Getting this data is out of scope for this IHE Devices Technical Framework: IHE Information Technology Infrastructure Technical Framework should be consulted for standards-based means for tracing a feed of ADT events (Patient Identify Feed) or querying this information based on information available at the point of care such as a bar-code scan of a patient identity wristband (Patient Data Query). In the context of the IHE Patient Care domain, this general problem is referred to as Patient Identity Binding and has been the subject of a Technical Framework Supplement in the past. At present, this data requirement is delegated to IHE Information Technology Infrastructure profiles. + +Reliable patient identity information is essential for correctly associating Patient Care Device data with the patient, which is obviously critical for safe and effective treatment. Consequently, unique identifiers and additional confirmatory factors such as patient name are listed as required by this profile. + +Table B.5-1: PID - Patient Identification segment + +[width="100%",cols="12%,9%,9%,11%,15%,10%,34%",options="header",] +|=== +|SEQ |LEN |DT |Usage |Card. |TBL# |Element name +|1 |4 |SI |X |[0..0] | |Set ID - PID +|2 |20 |CX |X |[0..0] | |Patient ID +|3 |250 |CX |C |[0..6] | |Patient Identifier List +|4 |20 |CX |X |[0..0] | |Alternate Patient ID - PID +|5 |250 |XPN |C |[0..6] | |Patient Name +|6 |250 |XPN |RE |[0..1] | |Mother’s Maiden Name +|7 |24 |DTM |RE |[0..1] | |Date/Time of Birth +|8 |1 |IS |RE |[0..1] |0001 |Administrative Sex +|9 |250 |XPN |X |[0..0] | |Patient Alias +|10 |705 |CWE |RE |[0..1] |0005 |Race +|11 |250 |XAD |RE |[0..1] | |Patient Address +|12 |4 |IS |RE |[0..1] |0289 |County Code +|13 |250 |XTN |RE |[0..2] | |Phone Number - Home +|14 |250 |XTN |X |[0..1] | |Phone Number - Business +|15 |705 |CWE |RE |[0..1] |0296 |Primary Language +|16 |705 |CWE |RE |[0..1] |0002 |Marital Status +|17 |705 |CWE |RE |[0..1] |0006 |Religion +|18 |705 |CX |RE |[0..1] | |Patient Account Number +|19 |16 |ST |X |[0..0] | |SSN Number - Patient +|20 |25 |DLN |RE |[0..1] | |Driver's License Number - Patient +|21 |705 |CX |RE |[0..1] | |Mother's Identifier +|22 |705 |CWE |RE |[0..1] |0189 |Ethnic Group +|23 |705 |ST |RE |[0..1] | |Birth Place +|24 |1 |ID |RE |[0..1] |0136 |Multiple Birth Indicator +|25 |2 |NM |RE |[0..1] | |Birth Order +|26 |705 |CWE |RE |[0..1] |0171 |Citizenship +|27 |705 |CWE |RE |[0..1] |0172 |Veterans Military Status +|28 |705 |CWE |RE |[0..1] |0212 |Nationality +|29 |24 |DTM |RE |[0..1] | |Patient Death Date and Time +|30 |1 |ID |RE |[0..1] |0136 |Patient Death Indicator +|31 |1 |ID |RE |[0..1] |0136 |Identity Unknown Indicator +|32 |20 |IS |RE |[0..1] |0445 |Identity Reliability Code +|33 |24 |DTM |RE |[0..1] | |Last Update Date/Time +|34 |241 |HD |RE |[0..1] | |Last Update Facility +|35 |705 |CWE |RE |[0..1] |0446 |Species Code +|36 |250 |CWE |C |[0..1] |0447 |Breed Code +|37 |80 |ST |C |[0..1] | |Strain +|38 |705 |CWE |RE |[0..2] |0429 |Production Class Code +|39 |705 |CWE |RE |[0..1] |0171 |Tribal Citizenship +|=== + +The following describes the IHE PCD usage of those fields which have a usage other than X in the above table and have IHE PCD usage notes added to the general definitions in the HL7 2.6 standard. + +PID-3 Patient Identifier List + +Definition: This field contains the list of identifiers (one or more) used by the healthcare facility to uniquely identify a patient (e.g., medical record number, billing number, birth registry, national unique individual identifier, etc.). In Canada, the Canadian Provincial Healthcare Number is used in this field. + +Component PID-3.1 (in terms of the CX data type, CX-1) "ID number", is required except where noted under particular transactions. PID-3.4 (CX-4) "Assigning authority", and PID-3.5 (CX-5) "Identifier Type Code" are required for each identifier if they are known (for example if they are ordinarily included in ADT messages at the institution), but may be empty if they are not known. See Appendix CX Data Type. Note that PID-3.4 is an Entity Identifier data type, so it may have subcomponents. + +The workflow and mechanism by which patient identification is bound to the data from a particular PCD device is outside of the scope of the IHE PCD Framework. Common implementations employ either automated or manual entry based on information provided by an authoritative source of patient identity. + +The IHE PCD recognizes that it is critical for data to be associated with the correct patient, thus the general rule that at least PID-3 and PID-5 be available for at least two-factor patient identification, but that there are also situations like emergency admissions where it may be desirable to collect data before an authoritative patient identification is available, for later association with the patient’s other data. Only after appropriate study, risk analysis, and defined risk mitigation measures determined by the provider institution in consultation with the manufacturers of the systems involved, a defined method for deferred association of patient data could be designed. In such a case, these fields, instead of being populated with authoritative patient identity information, could be populated with agreed-on special values (like an automatically generated “stat admit” patient identifier and a well-known special value in PID-5 indicating the temporary situation) pending the later human-validated merging of the data. + +The IHE PCD recognizes that for some use cases, such as medication administration, additional identification information or other patient demographic information is required in addition to an organizationally assigned unique identifier. Patient name, date of birth, gender, and other information are commonly used to provide the additional patient identification context for these use cases. Additional patient demographic information is provided by the fields of the PID segment and the patient location, which is often a key element in PCD communications, is provided in the PV1-3 element. + +PID-5 Patient Name + +Definition: This field contains the names of the patient; the primary or legal name of the patient is reported first. Therefore, the name type code in this field should be "L - Legal" if such a name is available. If no name is available, the name type code should be "U – unspecified", and the other components should be empty. All other codes in HL7 Table 0200 – Name Type are also acceptable. Note that "last name prefix" is synonymous to "own family name prefix" of previous versions of HL7, as is "second and further given names or initials thereof" to "middle initial or name". Multiple given names and/or initials are separated by spaces. + +The workflow and mechanism by which patient name is bound to the data from a particular PCD device is outside of the scope of this version of the IHE PCD Framework. Common implementations employ either automated or manual entry based on information provided by an authoritative source of patient identity. The workflow and transactions to bind patient name are included on the IHE PCD Roadmap for consideration in future versions of the IHE PCD Framework. + +See Appendix C.8 XPN Type for further information. + +PID-6 Mother’s Maiden Name + +Definition: This field contains the family name under which the mother was born (i.e., before marriage). It is used to distinguish between patients with the same last name. + +See Appendix C.8 XPN Type for further information. + +PID-7 Date/Time of Birth + +See Appendix C.4, DTM – date/time for further information on how the specification of times in IHE PCD differs from the HL7 v. 2.6 representation + +PID-8 Administrative Sex + +Definition: This field contains the patient’s sex. Refer to HL7 User-defined Table 0001 - Administrative Sex for suggested values. + +Table B.5-2: HL7 User-defined Table 0001 - Administrative Sex + +[width="100%",cols="32%,36%,32%",options="header",] +|=== +|Value |Description |Comment +|F |Female | +|M |Male | +|O |Other | +|A |Ambiguous | +|N |Not applicable | +|=== + +PID-10 Race (CWE) + +Definition: This field refers to the patient’s race. Refer to User-defined Table 0005 - Race for suggested values. The second triplet of the CWE data type for race (alternate identifier, alternate text, and name of alternate coding system) is reserved for governmentally assigned codes. + +Table B.5-3: HL7 User-defined Table 0005 - Race + +[width="100%",cols="17%,60%,23%",options="header",] +|=== +|Value |Description |Comment +|1002-5 |American Indian of Alaska Native | +|2028-9 |Asian | +|2054-5 |Black or African American | +|2076-8 |Native Hawaiian of Other Pacific Islander | +|2106-3 |White | +|2131-1 |Other Race | +|=== + +PID-11 Patient Address + +Components: ^ ^ ^ ^ ^ ^
^ ^ ^ ^
^
^ ^ + +Subcomponents for Street Address (SAD): & & + +Subcomponents for Address Validity Range (DR): & + +Subcomponents for Range Start Date/Time (DTM):