diff --git a/.ci/asciidoc-converter/build.gradle b/.ci/asciidoc-converter/build.gradle index cd0a1cc..a8b5c85 100644 --- a/.ci/asciidoc-converter/build.gradle +++ b/.ci/asciidoc-converter/build.gradle @@ -14,7 +14,7 @@ asciidoctor { sourceDir file('../../asciidoc') sources { include 'IHE_DEV_Suppl_PCIM.adoc' - include 'cp-dev-*.adoc' + include 'CPs/cp-dev-*.adoc' include 'index.adoc' } diff --git a/asciidoc/archived/cp-dev-012.adoc b/asciidoc/CPs/approved/cp-dev-012.adoc similarity index 100% rename from asciidoc/archived/cp-dev-012.adoc rename to asciidoc/CPs/approved/cp-dev-012.adoc diff --git a/asciidoc/archived/cp-dev-013.adoc b/asciidoc/CPs/approved/cp-dev-013.adoc similarity index 100% rename from asciidoc/archived/cp-dev-013.adoc rename to asciidoc/CPs/approved/cp-dev-013.adoc diff --git a/asciidoc/archived/cp-dev-016.adoc b/asciidoc/CPs/approved/cp-dev-016.adoc similarity index 100% rename from asciidoc/archived/cp-dev-016.adoc rename to asciidoc/CPs/approved/cp-dev-016.adoc diff --git a/asciidoc/archived/cp-dev-017.adoc b/asciidoc/CPs/approved/cp-dev-017.adoc similarity index 100% rename from asciidoc/archived/cp-dev-017.adoc rename to asciidoc/CPs/approved/cp-dev-017.adoc diff --git a/asciidoc/archived/cp-pcd-162.adoc b/asciidoc/CPs/approved/cp-pcd-162.adoc similarity index 100% rename from asciidoc/archived/cp-pcd-162.adoc rename to asciidoc/CPs/approved/cp-pcd-162.adoc diff --git a/asciidoc/cp-dev-018.adoc b/asciidoc/CPs/cp-dev-018.adoc similarity index 100% rename from asciidoc/cp-dev-018.adoc rename to asciidoc/CPs/cp-dev-018.adoc diff --git a/asciidoc/cp-dev-019.adoc b/asciidoc/CPs/cp-dev-019.adoc similarity index 100% rename from asciidoc/cp-dev-019.adoc rename to asciidoc/CPs/cp-dev-019.adoc diff --git a/asciidoc/IHE_DEV_Suppl_PCIM.adoc b/asciidoc/IHE_DEV_Suppl_PCIM.adoc index c7a7d17..0c368eb 100644 --- a/asciidoc/IHE_DEV_Suppl_PCIM.adoc +++ b/asciidoc/IHE_DEV_Suppl_PCIM.adoc @@ -71,7 +71,7 @@ The current version of the IHE Devices Domain Technical Framework can be found a [chapter] = Introduction to This Supplement -This supplement to the IHE Devices Technical Framework adds rationale and implementation details of the Point-of-Care Identity Management Profile to the Framework, providing a means for standards-based exchange between systems of information collected and confirmed at the point-of-care tracking the set of medical devices originating observations about each patient. +This supplement to the IHE Devices Technical Framework adds rationale and implementation details of the Point-of-Care Identity Management (PCIM) Profile to the Framework. It defines a multi-protocol approach in which equivalent PCIM functionality can be implemented using HL7 v2, FHIR, or SDC transactions for standards-based exchange between systems at the point-of-care. == Open Issues and Questions @@ -146,22 +146,52 @@ rather, they are appendices to the IHE Technical Frameworks General Introduction |=== |=== -|Transaction Name and Number|Definition|Transaction OID +|Transaction Name and Number|Protocol|Definition|Transaction OID -|Filter Associations -(DEV-19) -|A Device-Patient Association Consumer sends an optional query to a Device-Patient Association Manager with filter criteria. The Device-Patient Association Manager sets up a real-time subscription with the specified filter criteria applied. +|Filter Associations (DEV-19) +|HL7 v2 +|A Device-Patient Association Consumer sends an optional query to a Device-Patient Association Manager with filter criteria. The Device-Patient Association Manager sets up a real-time subscription with the specified filter criteria applied. |1.3.6.1.4.1.19376.1.6.1.19.1 -|Communicate Association State -(DEV-51) +|Communicate Association State (DEV-51) +|HL7 v2 |A Device-Patient Association Reporter asserts to a Device-Patient Association Manager that a device has been associated or disassociated with a patient and optional location. It may also report updated data for a previously reported assertion. -|1.3.6.1.4.1.19376.1.6.1.51.1 +|1.3.6.1.4.1.19376.1.6.1.51.1 -|Report Association State -(DEV-52) +|Report Association State (DEV-52) +|HL7 v2 |A Device-Patient Association Manager reports to a Device-Patient Association Consumer that a device has been associated or disassociated with a patient with optional location. It may also report an update for an existing association. |1.3.6.1.4.1.19376.1.6.1.52.1 + +|Filter Associations (DEV-19-FHIR TBD) +|FHIR +|A Device-Patient Association Consumer sends an optional query to a Device-Patient Association Manager with filter criteria. The Device-Patient Association Manager sets up a real-time subscription with the specified filter criteria applied. +|TBD + +|Communicate Association State (DEV-51-FHIR TBD) +|FHIR +|A Device-Patient Association Reporter asserts to a Device-Patient Association Manager that a device has been associated or disassociated with a patient and optional location. It may also report updated data for a previously reported assertion. +|TBD + +|Report Association State (DEV-52-FHIR TBD) +|FHIR +|A Device-Patient Association Manager reports to a Device-Patient Association Consumer that a device has been associated or disassociated with a patient with optional location. It may also report an update for an existing association. +|TBD + +|Filter Associations (DEV-19-SDC TBD) +|SDC +|A Device-Patient Association Consumer sends an optional query to a Device-Patient Association Manager with filter criteria. The Device-Patient Association Manager sets up a real-time subscription with the specified filter criteria applied. +|TBD + +|Communicate Association State (DEV-51-SDC TBD) +|SDC +|A Device-Patient Association Reporter asserts to a Device-Patient Association Manager that a device has been associated or disassociated with a patient and optional location. It may also report updated data for a previously reported assertion. +|TBD + +|Report Association State (DEV-52-SDC TBD) +|SDC +|A Device-Patient Association Manager reports to a Device-Patient Association Consumer that a device has been associated or disassociated with a patient with optional location. It may also report an update for an existing association. +|TBD |=== @@ -246,12 +276,12 @@ None = 7 Point-of-Care Identity Management (PCIM) Profile -The Point-of-Care Identity Management (PCIM) Profile is a Transport Profile specifying HL7 v2 standard messaging for devices and IT systems at a point-of-care to exchange and synchronize information about the identity of specific devices collecting clinical information about a specific patient, to: +The Point-of-Care Identity Management (PCIM) Profile is a multi-protocol Transport Profile specifying HL7 v2, FHIR, and SDC transactions for devices and IT systems at a point-of-care to exchange and synchronize information about the identity of specific devices collecting clinical information about a specific patient, to: - Assist in the reliable association of the collected data to the proper patient record, based on first-hand observation and data entry by a person at the point-of-care, specifically designed to avoid wrong attribution of data from before or after the period of actual measurement on the patient. - Assist in maintaining a correct "`census`" of devices that frequently move between patients such as infusion pumps, and mechanical ventilators. -The messaging defined provides for capable devices to originate messages asserting association and disassociation to a particular patient, for human interface software components to afford users the opportunity to originate or confirm association or disassociation assertions, for one or more systems to receive and persist device-patient association information, to distribute reporting messages or receive and respond to queries about such associations. +The transactions defined provide for capable devices and systems to originate association and disassociation assertions for a particular patient, for human interface software components to afford users the opportunity to originate or confirm such assertions, for one or more systems to receive and persist device-patient association information, and to distribute reporting updates or receive and respond to association queries. == 7.1 PCIM Actors, Transactions, and Content Modules @@ -274,7 +304,6 @@ Actors which have a required grouping are shown in conjoined boxes (see Section | Reporter | +------------------+ | - DEV-51 | Communicate | Association | State | @@ -287,8 +316,7 @@ Actors which have a required grouping are shown in conjoined boxes (see Section | Manager | | in the MEMDMC profile as a MEM | +------------------+ | DMIC actor to obtain configuration | | ^ | information. | - DEV-52 | | DEV-19 \------------------------------------/ - Report | | Filter + Report | | Filter \------------------------------------/ Association | | Associations State | | | | @@ -306,10 +334,10 @@ Actors which have a required grouping are shown in conjoined boxes (see Section **Figure 7.1-1: PCIM Actor Diagram** -Table 7.1-1 lists the transactions for each actor directly involved in the PCIM Profile. +Table 7.1-1, Table 7.1-2, and Table 7.1-3 list the transactions for each actor directly involved in the PCIM Profile for HL7 v2, FHIR, and SDC respectively. To claim compliance with this profile, an actor shall support all required transactions (labeled "`R`") and may support the optional transactions (labeled "`O`"). -**Table 7.1-1: PCIM Profile - Actors and Transactions** +**Table 7.1-1: PCIM Profile - Actors and Transactions (HL7 v2)** |=== |Actors|Transactions|Initiator or Responder|Optionality|Reference @@ -321,7 +349,7 @@ To claim compliance with this profile, an actor shall support all required trans |DEV TF-2 3.51 .2+|Device-Patient Association Consumer -|Consume Association State +|Report Association State |R |R |DEV TF-2: 3.52 @@ -331,7 +359,7 @@ To claim compliance with this profile, an actor shall support all required trans |DEV TF-2: 3.19 .3+|Device-Patient Association Manager -|Consume Association State +|Communicate Association State |R |R |DEV TF-2: 3.51 @@ -348,6 +376,84 @@ To claim compliance with this profile, an actor shall support all required trans |=== +**Table 7.1-2: PCIM Profile - Actors and Transactions (FHIR)** + +|=== +|Actors|Transactions|Initiator or Responder|Optionality|Reference + +|Device-Patient Association Reporter +|Communicate Association State +|I +|R +|DEV TF-2: FHIR transaction section TBD + +.2+|Device-Patient Association Consumer +|Report Association State +|R +|R +|DEV TF-2: FHIR transaction section TBD +|Filter Associations +|I +|O +|DEV TF-2: FHIR transaction section TBD + +.3+|Device-Patient Association Manager +|Communicate Association State +|R +|R +|DEV TF-2: FHIR transaction section TBD + +|Report Association State +|I +|R +|DEV TF-2: FHIR transaction section TBD + +|Filter Associations +|R +|O +|DEV TF-2: FHIR transaction section TBD + +|=== + +**Table 7.1-3: PCIM Profile - Actors and Transactions (SDC)** + +|=== +|Actors|Transactions|Initiator or Responder|Optionality|Reference + +|Device-Patient Association Reporter +|Communicate Association State +|I +|R +|DEV TF-2: SDC transaction section TBD + +.2+|Device-Patient Association Consumer +|Report Association State +|R +|R +|DEV TF-2: SDC transaction section TBD +|Filter Associations +|I +|O +|DEV TF-2: SDC transaction section TBD + +.3+|Device-Patient Association Manager +|Communicate Association State +|R +|R +|DEV TF-2: SDC transaction section TBD + +|Report Association State +|I +|R +|DEV TF-2: SDC transaction section TBD + +|Filter Associations +|R +|O +|DEV TF-2: SDC transaction section TBD + +|=== + === 7.1.1 Actor Descriptions and Actor Profile Requirements Requirements are documented in Transactions (Volume 2) and Content Modules (Volume 3). @@ -1820,6 +1926,505 @@ PRT|1|UC||EQUIP^EQUIP^HL70912|||||3 WEST ICU^3001^1|MON5596^^231A8456B1CB2366^EU PRT|2|UC||AUT^AUT^HL70912|58796^Ratched^N||||3 WEST ICU^3001^1||20160726230000 .... +== A.4 PCIM Association Information Model + +This section defines protocol-agnostic models for device-patient association data. +The models are used as semantic sources for HL7 v2, FHIR, and SDC mappings. + +=== A.4.1 Association Instance Model + +The Association Instance model represents the longitudinal, business-level association between one patient and one device. +It is the enduring record that in aggregate constitutes the source of truth that consumers rely on for the current or historical state of an association relationship, including lifecycle status and begin/end context. +Multiple event records may reference the same Association Unique Instance Identifier over time. + +==== A.4.1.1 Canonical Model Elements + +**Table A.4.1-1: Association Instance Canonical Model Elements** + +|=== +|Model Element|Cardinality|Definition + +|Association Unique Instance Identifier +|R +|Identifier that uniquely identifies the association instance in the local/community domain. + +|Association Status +|R +|Lifecycle status of the association instance. Captures the current state of the association, such as `active`, `inactive`, or `wrong`. + +|Association Begin Time +|R +|Time when the device-patient association began. + +|Association End Time +|C +|Time when the device-patient association ended. + +|Patient Identifier +|R +|Identifier that uniquely identifies the patient in the local/community domain. + +|Device Identifier +|R +|Identifier that uniquely identifies the device instance in the local/community domain. + +|Association Begin Location +|O +|Location of the device/patient when the association began. + +|Association End Location +|O +|Location of the device/patient when the association ended. + +|Asserter +|R +|Participant that asserted the association. May be a person or a system/device. + +|Validator +|C +|Participant who validates the association when it was not validated at initial reporting. +|=== + +==== A.4.1.2 HL7 v2 Mapping + +**Table A.4.1-2: Association Instance Canonical Model to HL7 v2 Mapping** + +|=== +|Model Element|HL7 v2 Mapping|Notes + +|Association Unique Instance Identifier +|OBR-3 (originating association) and OBR-29.2 (subsequent updates) +|OBR-3 identifies the update event; OBR-29.2 links updates back to the originating association instance identifier. + +|Association Status +|Derived from OBX-11 + OBX-5 (`OBX-3 = MDC_ATTR_EVT_COND`) +|`active` from active association state, `inactive` from disassociation/end state, `wrong` from wrong/error semantics (e.g., `OBX-11 = W`) per profile rules. + +|Association Begin Time +|PRT-11 in EQUIP participant segment +|Association start semantics are represented in PRT-11/PRT-12. + +|Association End Time +|PRT-12 in EQUIP participant segment +|Association end semantics are represented in PRT-11/PRT-12. + +|Patient Identifier +|PID-3 (Patient Identifier List) +|A unique identifier within scope is required. + +|Device Identifier +|PRT-10 in the EQUIP participant segment +|The device-as-subject is identified in the EQUIP PRT segment. + +|Association Begin Location +|PRT-9 in EQUIP participant segment and/or PV1-3 +|Begin location is interpreted from assertion/association message semantics. + +|Association Location at End +|PRT-9 in EQUIP participant segment and/or PV1-3 +|End location is interpreted from disassociation/end message semantics. + +|Asserter +|PRT with PRT-4.1 = `AUT` +|Person identity appears in PRT-5, system/device identity in PRT-10. + +|Validator +|PRT with PRT-4.1 = `RO` +|Used when verification is performed after initial assertion. +|=== + +==== A.4.1.3 FHIR R6 Mapping + +**Table A.4.1-3: Association Instance Canonical Model to FHIR R6 Mapping** + +|=== +|Model Element|FHIR R6 Candidate Mapping|Notes / Gaps + +|Association Unique Instance Identifier +|DeviceAssociation.identifier (association-instance identifier) and/or resource logical id +|Can be profiled as a specific identifier type for longitudinal correlation. + +|Association Status +|DeviceAssociation.status +|Direct mapping to status code values including `active`, `inactive`, and `entered-in-error`. + +|Association Begin Time +|DeviceAssociation.period.start +|Direct mapping. + +|Association End Time +|DeviceAssociation.period.end +|Direct mapping when known. + +|Patient Identifier +|DeviceAssociation.subject (Reference(Patient)) +|Identifier carried on Patient.identifier. + +|Device Identifier +|DeviceAssociation.device (Reference(Device)) +|Identifier carried on Device.identifier (e.g., UDI or other unique identifier). + +|Association Begin Location +|No single direct base element +|Candidate approaches include extension(s) and/or DeviceAssociation.context (e.g., Encounter -> location) with start-time semantics constrained by profile. + +|Association Location at End +|No single direct base element +|Gap: no dedicated end-location element; expected through extension and/or related context resources. + +|Asserter +|No direct base element in DeviceAssociation; candidate Provenance.agent(who) +|Asserter identity/role is expected to be constrained in profile. + +|Validator +|No direct base element in DeviceAssociation; candidate Provenance.agent with verifier role +|Verification actor and timestamp are expected to map through Provenance and/or profile extensions. +|=== + +==== A.4.1.4 SDC XML Mapping + +**Table A.4.1-4: Association Instance Canonical Model to SDC XML Mapping** + +|=== +|Model Element|SDC XML Mapping|Notes / Gaps + +|Association Unique Instance Identifier +|`msg:GetContextStatesResponse/msg:ContextState/@Handle` (and corresponding `msg:*ContextReport` paths) +|`@Handle` is the base candidate for longitudinal instance identity. + +|Association Status +|Derived from `msg:GetContextStatesResponse/msg:ContextState/@ContextAssociation` +|`active` maps to associated state (`Assoc`), `inactive` maps to disassociated state (`Dis`). `entered-in-error` has no single direct base element and requires profile rules/extension. + +|Association Begin Time +|`msg:GetContextStatesResponse/msg:ContextState/@BindingStartTime` (and corresponding `msg:*ContextReport` paths) +|Direct mapping from binding lifecycle. + +|Association End Time +|`msg:GetContextStatesResponse/msg:ContextState/@BindingEndTime` (and corresponding `msg:*ContextReport` paths) +|Direct mapping from binding lifecycle when present. + +|Patient Identifier +|`msg:GetContextStatesResponse/msg:ContextState[@xsi:type='pm:PatientContextState']/pm:Identification` +|Primary mapping for unique patient identity. + +|Device Identifier +|`msg:GetContextStatesResponse/msg:ContextState/@DescriptorHandle` linked to `pm:MdsDescriptor/pm:MetaData/pm:Udi/pm:DeviceIdentifier` and/or `pm:MetaData/pm:SerialNumber` +|Profile should define preferred identifier strategy (e.g., UDI vs serial). + +|Association Begin Location +|`msg:GetContextStatesResponse/msg:ContextState[@xsi:type='pm:LocationContextState']/pm:LocationDetail` with `@BindingStartTime` +|Location detail includes `@PoC`, `@Room`, `@Bed`, `@Facility`, `@Building`, `@Floor`. + +|Association Location at End +|`msg:GetContextStatesResponse/msg:ContextState[@xsi:type='pm:LocationContextState']/pm:LocationDetail` with `@BindingEndTime` +|Uses same structure as begin location with end-time context. + +|Asserter +|No direct base element in `pm:AbstractContextState` +|Nearest candidates are `pm:OperatorContextState` and extension content (`ext:Extension`); explicit AUT-equivalent source is not a base element. + +|Validator +|`msg:GetContextStatesResponse/msg:ContextState/pm:Validator` +|Maps to verifier semantics; participant identity uses `pm:InstanceIdentifier`. +|=== + +=== A.4.2 Event Canonical Model Elements + +The Event model represents a point-in-time assertion about an association instance, such as begin, end, correction, or entered-in-error scenarios. +Events are the protocol-transport units exchanged in transactions and are used to create, update, validate, or invalidate an Association Instance record. +In short: the instance is the longitudinal entity, and events are the time-stamped facts that evolve that entity. + +**Table A.4.2-1: Event Canonical Model Elements** + +|=== +|Model Element|Cardinality|Definition + +|Event Identifier +|R +|Identifier that uniquely identifies the event in the local/community domain. + +|Association Unique Instance Identifier +|R +|Identifier that uniquely identifies the association instance in the local/community domain. + +|Event Type +|R +|Whether the event is an assertion, a correction or flagging an existing event as wrong. + +|Event Recorded Time +|R +|Time that the event was recorded in the system. + +|Association/Disassociation State +|R +|Whether the event is an association or disassociation. + +|Association State Time +|C +|Time when the device-patient state occurred (e.g., when the device was connected or disconnected to the patient) and depends on the Association/Disassociation State. + +|Patient Identifier +|R +|Identifier that uniquely identifies the patient in the local/community domain. + +|Device Identifier +|R +|Identifier that uniquely identifies the device instance in the local/community domain. + +|Assertion Validation State +|R +|State indicating whether the association/disassociation assertion is validated at the time of reporting. + +|Location +|O +|Location of the device and patient recorded when the event occurs. + +|Asserter +|R +|Participant that asserted the event. May be a person or a system/device. + +|Validator +|C +|Participant who validates the assertion when it was not validated at initial reporting. +|=== + +=== A.4.3 Event Model HL7 v2 Mapping + +**Table A.4.3-1: Event Canonical Model to HL7 v2 Mapping** + +|=== +|Model Element|HL7 v2 Mapping|Notes + +|Event Identifier +|OBR-3 +|The Filler ID (OBR-3) is used to carry the event identifier, which uniquely identifies the event in the local/community domain. The first event in an association lifecycle (e.g., assertion) will generate the event identifier, and subsequent events in the lifecycle (e.g., correction, disassociation) will reference that same event identifier to link them together. + +|Association Unique Instance Identifier +|OBR-3 or OBR-29 +|OBR-3 for the unique instance identifier originating association event and OBR-29 for subsequent updates. + +|Event Type +|OBX-11 (Observation Result Status) +|Primary event-type semantics are conveyed by `OBX-11` (`R` asserted/unvalidated, `F` validated/final, `C` correction, `W` wrong). + +|Association/Disassociation State +|OBX-5 in the event-condition OBX (`OBX-3 = MDC_ATTR_EVT_COND`) +|Association vs disassociation is carried by MDC-coded event value (e.g., `MDC_EVT_ASSOCIATION_PATIENT_DEVICE` vs `MDC_EVT_DISASSOCIATION_PATIENT_DEVICE`). + +|Event Time +|OBR-7 and/or MSH-7 +|`OBR-7` is the primary clinical event time in the association observation; `MSH-7` is message creation time. + +|Association Time +|PRT-11 in the EQUIP participant segment +|Device association time semantics are represented in PRT-11/PRT-12. + +|Disassociation Time +|PRT-12 in the EQUIP participant segment +|Device association time semantics are represented in PRT-11/PRT-12. + +|Patient Identifier +|PID-3 (Patient Identifier List) +|A unique identifier within scope is required. + +|Device Identifier +|PRT-10 in the EQUIP participant segment. +|The device-as-subject is identified in the EQUIP PRT segment. + +|Assertion Validation State +|OBX-11 (Observation Result Status) +|`F` indicates validated. `R` indicates asserted but not validated. `C` and `W` carry correction/wrong semantics and are richer than a simple boolean state. + +|Location +|PRT-9 in the EQUIP participant segment and/or PV1-3 +|PV1-3 may convey ADT patient assigned location; PRT-9 can convey participant location context at the association/disassociation event time. + +|Asserter +|PRT with PRT-4.1 = `AUT` +|Person identity appears in PRT-5, system/device identity in PRT-10 as applicable. time is conveyed in PRT-11/PRT-12. + +|Validator +|PRT with PRT-4.1 = `RO` +|Used when verification is performed after initial assertion; time is conveyed in PRT-11/PRT-12. +|=== + +=== A.4.4 Event Model FHIR R6 Mapping + +The FHIR mapping in this section is based on FHIR R6 CI Build DeviceAssociation content (https://build.fhir.org/deviceassociation.html) and will be profiled further as PCIM FHIR transactions are specified. + +**Table A.4.4-1: Event Canonical Model to FHIR R6 Mapping** + +|=== +|Model Element|FHIR R6 Candidate Mapping|Notes / Gaps + +|Event Identifier +|DeviceAssociation.identifier +|Use a typed identifier slice/profile element for the event identifier. + +|Association Unique Instance Identifier +|DeviceAssociation.identifier (association-instance identifier) and/or resource logical id +|Can be profiled as a distinct identifier type from event identifier. + +|Event Type +|No direct base element in DeviceAssociation +|Gap: assertion/correction/wrong semantics are expected via `Provenance.activity` and/or profile extension. + +|Association/Disassociation State +|DeviceAssociation.status and/or DeviceAssociation.associationStatus +|Primary state is represented by association status. Disassociation is also reflected by a closed `period.end`. + +|Event Time +|No single direct base element; candidate `Provenance.recorded` (or `DeviceAssociation.meta.lastUpdated`) +|Gap: event-recorded timestamp should be explicitly profiled for interoperability. + +|Association Time +|DeviceAssociation.period.start +|Direct mapping. + +|Disassociation Time +|DeviceAssociation.period.end +|Direct mapping when known. + +|Patient Identifier +|DeviceAssociation.subject (Reference(Patient)) +|Identifier carried on Patient.identifier. + +|Device Identifier +|DeviceAssociation.device (Reference(Device)) +|Identifier carried on Device.identifier (e.g., UDI or other unique identifier). + +|Assertion Validation State +|No direct base element +|Gap: DeviceAssociation has `status` and `associationStatus`, but not explicit validation state equivalent to HL7 v2 `OBX-11 F/R`. Profile extension is expected. + +|Location +|No single direct base element +|Gap: no dedicated association/disassociation location pair. Candidate approaches include extension(s) and/or `DeviceAssociation.context` (e.g., Encounter -> location). + +|Asserter +|No direct base element in DeviceAssociation; candidate `Provenance.agent(who)` +|Gap: asserter identity/role and timestamp should be constrained via profile. + +|Validator +|No direct base element in DeviceAssociation; candidate `Provenance.agent` with verifier role +|Gap: verification actor and verification timestamp are expected to map through Provenance and/or profile extensions. +|=== + +=== A.4.5 Event Model SDC XML Mapping + +The SDC mapping in this section is based on: + +* `ExtensionPoint.xsd` +* `BICEPS_ParticipantModel.xsd` +* `BICEPS_MessageModel.xsd` + +The key model anchor is `pm:MdsDescriptor/pm:SystemContext`, which declares supported context descriptor types. +Context state instances are exchanged through `msg:GetContextStatesResponse/msg:ContextState`, `msg:EpisodicContextReport/msg:ReportPart/msg:ContextState`, and related context messages where `ContextState` is typed as `pm:AbstractContextState` and specialized by context type. + +**Table A.4.5-1: SDC SystemContext and *Context Types** + +|=== +|Context Type|Descriptor in SystemContext|State Type|Key State Content + +|Patient +|`pm:SystemContext/pm:PatientContext` +|`pm:PatientContextState` +|`pm:Identification`, `pm:CoreData` + +|Location +|`pm:SystemContext/pm:LocationContext` +|`pm:LocationContextState` +|`pm:Identification`, `pm:LocationDetail` + +|Operator +|`pm:SystemContext/pm:OperatorContext` +|`pm:OperatorContextState` +|`pm:Identification`, `pm:OperatorDetails` + +|Workflow +|`pm:SystemContext/pm:WorkflowContext` +|`pm:WorkflowContextState` +|`pm:Identification` + +|Means +|`pm:SystemContext/pm:MeansContext` +|`pm:MeansContextState` +|`pm:Identification` + +|Ensemble +|`pm:SystemContext/pm:EnsembleContext` +|`pm:EnsembleContextState` +|`pm:Identification` +|=== + +**Table A.4.5-2: Event Canonical Model to SDC XML Mapping** + +|=== +|Model Element|SDC XML Mapping|Notes / Gaps + +|Event Identifier +|`msg:GetContextStatesResponse/msg:ContextState/@Handle` (and corresponding `msg:*ContextReport` paths) +|`@Handle` identifies the context state instance and is the best base candidate for event identifier. + +|Association Unique Instance Identifier +|`msg:GetContextStatesResponse/msg:ContextState/@Handle` +|Same handle is the base candidate to track a context association instance across updates. + +|Event Type +|No single direct base element +|Gap: correction/wrong semantics are not explicit in base context-state elements and require profile rules and/or extension. + +|Association/Disassociation State +|`msg:GetContextStatesResponse/msg:ContextState/@ContextAssociation` +|Direct mapping (`Assoc`/`Dis`; additional SDC values may appear per base model). + +|Event Time +|No single direct base element; candidate message/report timestamp where available +|Gap: base mapping relies on binding lifecycle times and message context; explicit event-recorded timestamp should be profiled. + +|Association Time +|`msg:GetContextStatesResponse/msg:ContextState/@BindingStartTime` (and corresponding `msg:*ContextReport` paths) +|Direct mapping from `pm:AbstractContextState` binding lifecycle. + +|Disassociation Time +|`msg:GetContextStatesResponse/msg:ContextState/@BindingEndTime` (and corresponding `msg:*ContextReport` paths) +|Direct mapping from `pm:AbstractContextState` binding lifecycle. `@ContextAssociation='Dis'` indicates disassociated state. + +|Patient Identifier +|`msg:GetContextStatesResponse/msg:ContextState[@xsi:type='pm:PatientContextState']/pm:Identification` +|Primary mapping for unique patient identity is `pm:Identification` in `pm:PatientContextState`. + +|Device Identifier +|`msg:GetContextStatesResponse/msg:ContextState/@DescriptorHandle` linked to `pm:MdsDescriptor`, then `pm:MdsDescriptor/pm:MetaData/pm:Udi/pm:DeviceIdentifier` and/or `pm:MetaData/pm:SerialNumber` +|Resolved by handle linkage from context state to descriptor and MDS metadata; profile must define preferred identifier (e.g., UDI vs serial). + +|Assertion Validation State +|`msg:GetContextStatesResponse/msg:ContextState/pm:Validator` and `@ContextAssociation` +|No single base boolean equivalent to HL7 v2 validated/unvalidated. `pm:Validator` captures confirming actors; profile rules are needed for exact semantics. + +|Location +|`msg:GetContextStatesResponse/msg:ContextState[@xsi:type='pm:LocationContextState']/pm:LocationDetail` with binding time context (`@BindingStartTime`/`@BindingEndTime`) +|Location detail includes `@PoC`, `@Room`, `@Bed`, `@Facility`, `@Building`, `@Floor`. + +|Asserter +|No direct base element in `pm:AbstractContextState` +|Gap: nearest candidates are `pm:OperatorContextState` and extension content (`ext:Extension`), but AUT-equivalent originator is not explicit in base schema. + +|Validator +|`msg:GetContextStatesResponse/msg:ContextState/pm:Validator` +|Maps well to verifier semantics; participant identity uses `pm:InstanceIdentifier`. +|=== + +=== A.4.6 Event Model Cross-Protocol Gaps and Profiling Requirements + +The following items are expected to be profiled in protocol-specific sections: + +* Explicit validation-state semantics harmonized across HL7 v2 `OBX-11`, FHIR, and SDC. +* A consistent representation of optional location at association and disassociation times. +* A consistent representation of asserter (AUT semantics). +* A consistent representation of validator (RO semantics), including verification time. + == B.7 OBR - Observation Request Segment === OBR-3 Filler Order Number @@ -1846,4 +2451,4 @@ No content modules [chapter] = Volume 4 -- National Extensions -No national extensions \ No newline at end of file +No national extensions diff --git a/asciidoc/archived/cp_nn4.adoc b/asciidoc/archived/cp_nn4.adoc deleted file mode 100644 index 758d42c..0000000 --- a/asciidoc/archived/cp_nn4.adoc +++ /dev/null @@ -1,221 +0,0 @@ -[.text-center] -= IHE Change Proposal - -[.text-center] -== Tracking Information -[cols="1,1"] -|=== - -|IHE Domain/Program -|DEV Domain / Patient Care Device (PCD) Program - -|Change Proposal ID: -|CP-PCD-NN4 - -|Change Proposal Status: -|Draft - -|Date of last update: -|2022-08-01 - -|Person Assigned: -|Bill Haralson - -|=== - -[.text-center] -== Change Proposal Summary Information - -[cols="1,1"] -|=== - -2+^|*PCIM Device-Patient Association Manager Error Responses* - -|Submitter’s Name(s) and e-mail address(es): -|Bill Haralson, William.Haralson@icumed.com - -|Submission Date: -|TBD - -|Integration Profile(s) affected: -|Point-of-Care Identity Management (PCIM) - -|Actor(s) affected: -|Device-Patient Association Manager + -Device-Patient Association Reporter - -|IHE Technical Framework or Supplement modified: -|PCIM Profile TI revision 1.1, dated 2018-12-07 - -|Volume(s) and Section(s) affected: -|Trial Implementation, Multiple Sections - -2+|Rationale for Change: - -Additional clarification on how the Device-Patient Association Manager reports errors back to the Device-Patient Association Reporter. New error codes defining the specific errors are added. - -This Change Proposal (CP) proposes changes to implement profile clarifications and positions for the above issues. - -|=== - -|=== - -| _Section 3.17.4.1.2_ *Message Semantics* _Add the following new section after this section on page 24:_ - -|=== - -[.text-left] - -*Section 3.17.4.2 Device-Patient Association Acknowledgment* - -[.text-left] - -The Device-Patient Association Manager validates the message and responds with a commit level acknowledgment message (ACK\^R01^ACK). If an error condition is detected and if MSH-16 (Application Acknowledgement Type) in the ORU\^R01^ORU_R01 message is valued as "ER" or "AL", the Device-Patient Association Manager responds with an application acknowledgment message (ACK\^R01^ACK). - -[.text-left] -If the message is accepted by the Device-Patient Association Manager, the commit acknowledgment will contain the value CA in MSA-1. If not, the commit acknowledgment will contain either CR or CE, based upon HL7 enhanced acknowledgment rules (see HL7 v2.6, Section 2.9.3.2). - -[.text-left] -Message acceptance is based on: - -[.text-left] -* All required segments and fields are present per this specification and the IHE Patient Care Device Technical Framework, Vol. 2 (PCD-TF-2): Transactions. -* No incorrect data types are present. -* Validation of fields that must contain specific values as defined in this specification and PCD-TF-2 (e.g., MSH-21 must be "correct value"). - -[.text-left] -If MSH-16 (Application Acknowledgement Type) is valued as "ER" or "AL", the Device-Patient Association Manager may report an application acknowledgement error using the application acknowledgement message (ACK\^R01^ACK) for errors such as: - -[.text-left] - -* Specified device is unknown. -* Specified device is associated with another patient. -* Specified patient is unknown. - -[.text-left] -If the message from the Device-Patient Association Reporter is rejected, the application acknowledgement will contain the value AR or AE in MSA-1, based upon HL7 enhanced acknowledgment rules (see 1140 HL7 v2.6, Section 2.9.2.2). The reason for rejection is provided in the ERR segment. - -|=== - -| _Section 3.18.4.2_ *Device-Patient Disassociation Acknowledgment,* _Replace the existing text with additional detail on error reporting:_ - -|=== - -[.text-left] -[.underline]#Existing Text:# - -[.text-left] -The reply to the Device-Patient Association Report is an ordinary HL7 Acknowledgment. - -[.text-left] -[.underline]#Proposed Text:# - -[.text-left] -The Device-Patient Association Manager responds to the Device-Patient Association Reporter using commit and application acknowledgments in a similar manner to PCD-17 requests. See section 3.17.4.2. - -[.text-left] -If MSH-16 (Application Acknowledgement Type) is valued as "ER" or "AL", the Device-Patient Association Manager may report an application acknowledgement error using the application acknowledgement Message (ACK\^R01^ACK) for errors such as: - -[.text-left] -* Specified device is unknown. -* Specified device is not associated with a patient. -* Specified patient is unknown. - -|=== - -| *A.1.2.1 MSH Message Header,* _Replace the existing text with the following:_ - -|=== - -[.text-left] -[.underline]#Existing Text:# - -[.text-left] -Since this message is effectively an unsolicited observation report, the contents of the MSH segment follow the specifications for [PCD-01] in PCD-TF-2 Appendix B.1, except that MSH-21 is valued “IHE_PCD_017^IHE PCD\^1.3.6.1.4.1.19376.1.6.4.17^ISO” to identify it as a message representing a device-patient association. - -[.text-left] -[.underline]#Proposed Text:# - -[.text-left] -Since this message is effectively an unsolicited observation report, the contents of the MSH segment follow the specifications for [PCD-01] in PCD-TF-2 Appendix B.1 with the following exceptions: - -[.text-left] -* MSH-16 values correspond to those found in PCD TF-2, Table 3.3.4.4.1-1. This allows the Device-Patient Association Reporter to indicate to the Device-Patient Association Manager whether it can process application acknowledgments and under what conditions to send the additional acknowledgment. The Device-Patient Association Manager must send (or not send) application acknowledgments as specified by this field. This profile recommends that MSH-16 always be set to “AL” (always) to receive complete message processing confirmation. If this is not possible, this value should be set to “ER” (error/reject). The MSH-16 value has no effect on Device-Patient Association Consumers that receive PCD-17 or PCD-18 messages. -* MSH-21 is valued “IHE_PCD_017^IHE PCD\^1.3.6.1.4.1.19376.1.6.4.17^ISO” to identify it as a message representing a device-patient association. - -|=== - -| *A.1.2.6 PRT - Participation (Observation Participation),* _Add the following two new section after this section on page 41:_ - -|=== - -[.text-left] -*A.1.2.7 MSA – Message Acknowledgment Segment* -[.text-left] -See PCD-TF-2 Appendix B.2. - -[.text-left] -*A.1.2.8 ERR – ERR Segment* -[.text-left] -Refer to PCD-TF-2 Appendix B.3 for general usage notes on the ERR segment. - -[.text-left] -The list of error codes that can occur during the processing of PCD-17 and PCD-18 messages are listed below. The application acknowledgment received from the Device-Patient Association Manager 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. - -[.text-left] -_Note that the definition of the range of error codes available for use by this profile is TBD. It is assumed that error codes will start at the lower limit of the range and be incremented by one as new error codes are added._ - -[cols="2,3,4",options=header] -|=== - -|Code -|Text -|Example - -|_Lower limit -|Other error -|Used when other errors are not applicable. - -|_Lower limit + 1_ -|Unknown device -|Specified device is unknown. - -|_Lower limit + 2_ -|Unknown patient -|Specified patient is unknown. - -|_Lower limit + 3_ -|Device is associated with another patient -|A device-patient association or disassociation request was received, but the device specified in the request is associated with a different patient. - -|_Lower limit + 4_ -|Device is not associated with a patient -|A device-patient disassociation request was received, but the device specified in the request is not associated with a patient. - -|_Lower limit + 5_ -|Unknown location -|Specified location is unknown. - -|_Lower limit + 6_ -|Device-Patient association rejected. -|Device-Patient Association Reporter sent an unvalidated Device-Patient association request (OBX-11 is not equal to \‘F\’). Association request was rejected by the participating user. - -|_Lower limit + 7_ -|User is unauthorized. -|Participating user is unauthorized to perform request. - -|_Lower limit + 8_ -|Unknown user -|Participating user is not known by the Device-Patient Association Manager. - -|=== - - - - - - - - - - diff --git a/asciidoc/archived/cp_nn5.adoc b/asciidoc/archived/cp_nn5.adoc deleted file mode 100644 index c2adc1b..0000000 --- a/asciidoc/archived/cp_nn5.adoc +++ /dev/null @@ -1,204 +0,0 @@ -[.text-center] -= IHE Change Proposal - -[.text-center] -== Tracking Information -[cols="1,1"] -|=== - -|IHE Domain/Program -|DEV Domain / Patient Care Device (PCD) Program - -|Change Proposal ID: -|CP-PCD-NN5 - -|Change Proposal Status: -|Draft - -|Date of last update: -|2023-11-30 - -|Person Assigned: -|Tom Kowalczyk - -|=== - -[.text-center] -== Change Proposal Summary Information - -[cols="1,1"] -|=== - -2+^|*PCIM Device-Patient Association Manager Error Responses* - -|Submitter’s Name(s) and e-mail address(es): -|Tom KOWALCZYK Tom.Kowalczyk@BBraunUSA.com - - -|Submission Date: -|TBD - -|Integration Profile(s) affected: -|Point-of-Care Identity Management (PCIM) - -|Actor(s) affected: -|Device-Patient Association Reporter (DPAR) + -Device-Patient Association Manager (DPAM) + -Device-Patient Association Consumer (DPAC) - - -|IHE Technical Framework or Supplement modified: -|PCIM Profile TI revision 1.1, dated 2018-12-07 - -|Volume(s) and Section(s) affected: -|Trial Implementation, Multiple Sections - -2+|Rationale for Change: - -It is expected that EMR systems will likely be common implementors the PCIM Device-Patient Association Reporter and Device-Patient Association Manager actors. Many EMR systems already have a barcode scanner setup that allows the clinician to scan the identities of the Device and Patient at the bedside. In the case where the Device is an infusion pump, the EMR may also already have an assigned infusion order that is planned to be used by that infusion pump and patient. In that case, the infusion pump (gateway?) will likely implement the PCIM Device-Patient Association Consumer actor. When the infusion pump receives an association for a patient, a device (the pump), and an an optional order ID, all three of these parameters (Patient ID, Device ID, and Order Number) can later be included in the infusion based documentation transactions (PCD-01 and PCD-10) as well as alert transactions (PCD-04) to the Alert Manager. So, when the EMR receives these infusion documentation transactions with the order ID included, the EMR is better able to place it in the appropriate eMAR location in its database to make referencing and signing easier for the responsible clinician. From the EMR’s perspective, the infusion documentation transactions can be filed much like it is today with fully auto-programmed infusions even though the infusions were manually programmed and never received a PCD-03 transaction. Finally, in the case of alerts and alarms, having the patient ID in PCD-04 transactions enables the receiving Alert Manager to determine which clinician or other personnel to send downstream PCD-06 messages for handling the alerting situation. - -|=== - -|=== - -| __Appendix A - Proposed Messages_ _On page 35 of the IHE Patient Care Device Technical Framework Supplement – Point-of-Care Identity Management (PCIM), Rev 1.1 – Trial Implementation, section A.1.1 Message Structure, replace Table A.1.1-1 as follows::_ - -|=== - -[.text-left] -[.underline]#Existing Table:# -Table A.1.1-1 Report Device Patient Association - -[cols="1,1"] -|=== -|Segments -|Description - -|MSH -|Message Header - -|[{ SFT }] -|Software Segment - -|[UAC] -|User Authentication Credential - -|PID Patient Identification - -|[PV1] Patient Visit Information (for room bed) - -|OBR -|Observation Request - -|{ -| - -|OBX -|Observation Result - -|{ PRT } -|Participation - -|} -| - - -|=== - -[.text-left] -[.underline]#Proposed Table:# -Table A.1.1-1 Report Device Patient Association - -[cols="1,1"] -|=== -|Segments -|Description - -|MSH -|Message Header - -|[{ SFT }] -|Software Segment - -|[UAC] -|User Authentication Credential - -|PID Patient Identification - -|[PV1] Patient Visit Information (for room bed) - -|[ORC] -|Common Order - -|OBR -|Observation Request - -|{ -| - -|OBX -|Observation Result - -|{ PRT } -|Participation - -|} -| - -|=== - -|=== - -| __Appendix A - ORC Common Order_ _add a new section “A.1.2.4 ORC Common Order”:_ - -|=== - - -[.text-left] -A.1.2.4 ORC Common Order -The Common Order segment is provided to enter the Order ID for this Device-Patient association, if it is know at the time of the associate/disassociate transaction. The table below identifies the fields in the ORC segment that are processed by the Device-Patient Association Manager actor and the Device-Patient Association Consumer. These are the requirements to pass message validation (same a that for the PIV actor): - -Appendix Table A.1.2.4-1: ORC Fields -[cols="1,1,1"] -|=== -|Field Number -|Field Name -|Requirement to Pass Validation - -|1 -|Order Control -|RE or XO - -|2 -|Placer Order Number -|ORC-2.1 must be populated - -|9 -|Date/Time of Transaction -|Must be in valid date/time format - -|19 -|Action By -|ORC-19.1 must be populated - -|=== - -[.text-left] -Also, rename the subsequent section and table numberings on pages 36-41 to their next sequential numbers - -[.text-left] - Section A.1.2.4 -> A.1.2.5 OBR Order Request -[.text-left] - Section A.1.2.5 -> A.1.2.6 OBX Observation (for Patient ID) - Table A.1.2.5-1 -> A.1.2.6-1: OBX Fields - Table A.1.2.5-2 -> A.1.2.6-2: OBX-5 Values - Table A.1.2.5-3 -> A.1.2.6-3: OBX-11 Values -[.text-left] - Section A.1.2.6 -> A.1.2.7 PRT Participation (Observation Participation) - Table A.1.2.6-1 -> A.1.2.7-1: PRT Fields - Table A.1.2.6-2 -> A.1.2.7-2: PRT-4 Values - Table A.1.2.6-3 -> A.1.2.7-3: PRT-11 Interpretation - Table A.1.2.6-4 -> A.1.2.7-4: PRT-12 Interpretation - - -