See also: Topic of Interest: What is a Central?

TF 1 C2: Use Case Feature 1: Synchronized Time Across Devices (STAD)

How do we want to handle the following scenario? C.2.4.3 Scenario: STAD 1.3 - Device is connected to network and cannot connect to a TS Service

Current suggestions for mitigations if the NTP server is not accessible for some reason due to a temporary failure:

• The simplest approach would be for the devices to continue to communicate time based on their internal clocks which tend to be pretty accurate for moderate lengths of time.
• What if the user wants to add a device to a network during a temporary failure?
  • Does the device wait until the time service is available to participate on the network?
  • manual time entry? backup server? other?
  • Double check with BPKP requirements and add risk management requirements if needed

Section Number

3:8.3.2.7 Safety, Effectiveness, Security Content Requirements & Considerations

Priority

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Issue

The text in this section's version comment box is inappropriately highlighted: "purpose of the"

Proposed Change

Remove the text highlight.

Section Number

Appendix 2:B Gateways

Priority

Medium

Issue

The mapping of Coded Value elements is inconsistent. The information about the CodingSystemVersion is only mapped within a translation.

Proposed Change

I suggest to always map the CodingSystemVersion information if available.

Section Number

All files with "#PUB TODO" included

Priority

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

Issue

Yellow highlighted blocks still appear in the master branch

Proposed Change

For those PUB TODO sections that have been resolved, remove the comment
For those PUB TODO that still remain, enclose in a comment section (//// ... ////)

Section Number

Repository root directory

Priority

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

Issue

For a release, there is a need to include a folder for the generated HTML files + the actual files.

Proposed Change

Create sdpi-supplement folder in the repository root directory
Move the public comment version of the generated HTML files into this folder.

Section Number

Document

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

Formal requirements are included in the SDPi supplement; however, they are not available as a set in a separate file that can be reviewed and integrated after publication. This includes association with test assertions and test cases/scenarios

Proposed Change

Add a processing step in the converter program, or add a separate tool, that pulls the requirements metadata out of the sources and captures it in a new file in the referenced-artifacts folder.

Section Number

TF.2 B.3 R8101

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

"R8101
If the MDIB contains several MDS elements that could operate in different pm:MdsState/@OperatingMode states, there
shall be a separate [PCD-01] message per MDS."

@MartinKasp : Do we really need separate messages of it is only possible that there are different operating modes, or is it only necessary if this is actually the case? I would assume the second case.
@PeterKranich : The HL7 MSH (Message Header) contains the Processing Id with the code whether the data are production or test data. The MSH only exists once per message.

Proposed Change

Keep current text.

Section Number

B.3.4.5.2 OBR-3 Filler Order Number

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

R8005
For the IHE DEC profile, the SOMDS DEC Gateway shall set the OBR-4 field to the service identifier of the SOMDS Provider.

TODO: how can we map the device type to the proposed SNOMED code from the SDC information? Should we use MDC codes
instead? What about the licensing issue with SNOMED code?
@MartinKasp asked: What does these questions refer to? SNOMED in general or specific codes?

TODO: special requirements for infusion pumps
@PeterKranich: See also the IHE TF-2. This relates to the discussions about infusion pumps and the medication that shall be provided in this field.

TODO: service ids need to be finalized

Proposed Change

Resolve all TODOs

Section Number

B.3 SDPi DEC Gateway — Mapping

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

When the MDIB contains multiple MDS elements with different Patient / Location context information, the gateway cannot export the data in one single HL7 message since the PID and PV1 segment must not be exit multiple times in the HL7 message.

Proposed Change

Although the HL7 standard allows multiple patient results in one message (multiple PID and PV1 segements), systems have problems to parse the messages with multiple PID and PV1 segements. Therefore, only data from multiple MDS shall be exported in one message when the PID and PV1 segement content is identical for all MDS elements.

Section Number

2:B.3.4.6.13 OBX-18 Equipment Instance Identifier

Priority

High

Issue

Currently it is not possible to identify the medical device from which the data should be sent in an HL7 message.
The UDI is not available for all devices and alternatives for uniquely identifying a device shall be defined.

Proposed Change

I suggest to add an extension to BICEPS pm:MdsDescriptor/pm:MetaData for the UUID of a device (as stated in https://sourceforge.net/p/opensdc/ieee11073-10207/351/ )
The UUID, serial number and model number can then be mapped to repeated OBX-18 segments.

This comprises the abstract model and MDPWS appendix.

Section Number

C.3 Use Case Feature 2: C.3.3 & C.3.4

Priority

Medium
Could be postponed to version 1.1

Issue

How do we handle conflicting patient information?
This needs to be solved together with the whole device coupling discussion.

Proposed Change

Describe device coupling mechanism (patient vs. location based) and add a use case like:
Given: Dashboard can connect to devices providing patient information (patient context)
When: The patient information is contradicting.
Then: The Dashboard will display an error message.

See Topic: Profiling BICEPS Services in SDPi-P description cell (a separate topic discussion page has not been created.

This discussion will be added to TF-2 Appendix A MDPWS.

Section Number

References and links to specific IHE actors throughout the supplement

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

*When referring to a specific IHE actor (e.g., SOMDS actor), the word actor should be capitalized; however, sometimes the word actor is dropped completely like in Section 10.1.1.3 (IHE prefers to drop the word "actor" after the name except in instances where it is needed for clarity).

The supplement is inconsistent in this regard. Sometimes actor follows the actor name, sometimes not.

Also, the link text to an actor is sometime italicized and sometimes not*

Proposed Change

- Decide on how you want to refer to actors and be consistent throughout the document (recommendation is to remove the word "actor" except in cases where is is need for clarity (like in this sentence from Section 10.1.1.4 "A SOMDS Connector can implement both SOMDS Consumer and SOMDS Provider actors.)
- Decide if links to specific actors should be italicized and be consistent throughout the document

See also: https://confluence.hl7.org/pages/viewpage.action?pageId=131051997

Section Number

C5.4.3ff.

Priority

Medium

Issue

If backfilling is supposed to work, we need to define at least a validation mechanism and a way to assign data to a patient/location/ensemble.

Proposed Change

Add information to enable backfilling once the device coupling topic is resolved.

See Topic: Security Certificate Provisioning.

Note: TOI won't be fully resolved in SDPi 1.0. But a VERY simple guidance will be added (Vol1, SDPi-P SES)

From SDPi 1.0 Workshop: David will provide a general description in SDPi-P, SES. Needs to be revisited at a later date together with Accelerator program.

Update SDPi 1.1/1.2 workshop: We have three different concerns to solve: Access control, transport layer security and establishing vendor to vendor trust. In this version, we'll document the current status.

Access control:
- In the responsibility of the hospital
- Currently only supported by technologically advanced hospitals
- For the time beeing, we use allowlists to supplement the non-existing infrastructure (also replaces revocation of certificates) - this is burdensome for the customers but solves the problem (Format of the allowlist will be specified in version 1.3)
- Technologically advanced hospitals can use their own certificates for network access but should not be involved in the trust debate
---> come up with recommendations, but no requirement for devices.

Transport layer security:
- Done by TLS
- Currenly mixed with layer three
- Will be placed on the Glue and PKP revision agenda
---> Briefly describe current status

Compliance to standards - vendor to vendor trust

• Vision: Will be done by an independent organization in the future. Supported by a SDPi conformity assessment program to pave the way.
• For the time beeing, vendors sign their own certificates. Trust is established based on agreements between vendors.
  ---> Describe the current status and future vision.

Follow up actions are described in the related tickets (#197, #198 , #199 ).

Section Number

TF-2 sections B.3.3 Private MDC Codes Consideration

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

MDC private code is not a unique code but rather vendor specific. Therefore, pm_Translation shall be used to provide an alternative code system for the same code. We agree that this makes sense. However, if we really like to have this strict definition for the gateway, we will need also a strict requirement for SOMDS Provider that is more specific then bpkp:TR1358.

Proposed Change

Two alternatives are beiing discussed:

a) For private codes there has to be one pm:Translation with pm:Type/https://github.com/code = pm:Type/pm:Translation/https://github.com/code (more translations are allowed, but exactly one that has https://github.com/code = https://github.com/code)
b) For private codes there has to be exactly one pm:Translation fulfilling a) and no more translations are allowed

See also: https://confluence.hl7.org/pages/viewpage.action?pageId=104579763

For HIS the information whether a metric is sent periodically or not can be helpful. As of IHE-TF2 this information can be reported in OBX-17.

Section Number

TF-1 and TF-3

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

Though requirements blocks have been added to TF-2 and a few places in TF-3, there are none in TF-1 and more are needed for TF-3.

Proposed Change

During the Public Comment period, add requirements blocks in both Volume 1 and Volume 3. Comprehensive coverage is not required; however, the core requirements (e.g., required actors and transactions) or the need for secure connections, should be added before the Trial Implementation is published and before CAT testing is actively pursued.

See Topic: SystemContext Profiling & Use confluence page.

NOTE: For SDPi 1.0 will introduce the topic and provide some basic guidance; full treatment will be advanced in SDPi 1.x and later versions.

Section Number

TF-0 Appendix B "Discovery Scope" table entry.

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

Comment from @MartinKasp in IHE/sdpi-fhir#289 -- "This definition would also fit perfectly to the Ensemble Context. The connection to the discovery process is missing in the definition. Not really sure how we can fix this, maybe adding some technical details or details for the specific BICEPS-over-MDPWS implementation?"

Proposed Change

NOTE: For SDPi 1.0, Ensemble Context is explicitly out-of-scope; so this label has been set to 1.x

Discuss issue and determine how to best support this with in the SDPi specifications.

See Topic: MDIB Version Update Guidelines description in the Topics of Interest table (no page has been created).

Note: TOI won't be fully resolved in SDPi 1.0 (will involve BICEPS changes). But some general guidance to be added (Vol3..or 1).

Craft the content for the TF-2 Appendix B Common Gateway section.

This section shall describe the commonalities of the SDC to IHE DEC and IHE ACM mapping. This could be an overview.

Section Number

R8066

Priority

Martin's list

Issue

R8066: IHE TF-2 only supports one source. When there are multiple sources, only the first one should be used!?

Proposed Change

Needs further discussion

See also: https://confluence.hl7.org/pages/viewpage.action?pageId=131051997

See Topic: SDPi-xC with Mixed Device Safety Classes on confluence.

NOTE: This topic will remain open after SDPi 1.0 BUT it was determined to add "guidance" for the issue in 1.0.

Specifically (from 12 Aug, item 3.b): For SDPi 1.0, metrics and alerts can be kept simple with guidance for when to use Inf(ormation) & MedA, with MedB & MedC out-of-scope for SDPi 1.0 Also, it should be determined where in TF-1, -2 & -3 this guidance should be included ... possibly all three. For example, a general discussion in the SDPi-P, -R & -A profile (Overview / Concepts) sections, perhaps a TF-2 if there is technical / transactional relevance, and definitely in TF-3 for the BICEPS semantics handling in general for MDIB elements that have a SafetyClassification associated with them. Also factor in the SES sections - perhaps in the boilerplate template for those sections.

Given that SDPi 1.0 includes the SOMDS ACM Gateway actor (SDPi-A profile), there may be some transactional relevance. The draft HL7 FHIR DeviceAlert resource description also includes a SafetyClass mapping to SafetyClassification. The pathway for this SOMDS FHIR gateway should also be contemplated in the SDPi 1.0 content editorial considerations.

This issue includes the following tasks:

• Determine the editorial approach (near and long term) for integration of BICEPS SafetyClassification in to SDPi specifications
• Add SafetyClassification content into the SDPi specification
• Add the Mixed Safety Classes interim (SDPi 1.0) guidance into the SDPi specification

See also: Topic: MDIB/MDS Modeling for Device Aggregators

Section Number

TF-2:B.4.4.7.2

Priority

Martin's list

Issue

For the B.4.4.7.2 Event Identification OBX Segment and Table TF-2:B.4.4.7.2.2-116. OBX Event Identification Mapping - Physiological Alert Event, the alert text can be static and sourced by the AlertConditionDescriptor, or dynamic when the source is changing the alert text (Cause Info). This is missing and also the description what shall be used. This also applies to Table TF-2:B.4.4.7.2.3-117. OBX Event Identification Mapping - Technical Alert Event.

Proposed Change

Decide if we need to use static or dynamic texts and document accordingly.

See also: Topic: SDPi BICEPS Extension Namespace

Section Number

Table TF-2:B.3.4.6.13-89. OBX-18 Equipment Instance Identifier Mapping - VMD level

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

Discuss ToDo statement: TODO: which identifer to use on VMD level?

Comment from @MartinKasp : Currently, we can only add pm:Metadata using an extension. We could define this here in SDC and use these values for this mapping if provided.
Otherwise, pm:ProductionSpecification elements could be used.

TF 1 C2: Use Case Feature 1: Synchronized Time Across Devices (STAD)

We agree that NTP is mandatory, since SDC cannot work without it. Manual time change shall not be allowed.
(For small "island" setups we can still run the NTP server on one of the components but that doesnt change the fact that it's NTP as defined in IHE-CT profile).

Add a requirement that explicitly forbids changing the time manually, if an ntp server is available.

Section Number

Document

Priority

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

Issue

The text "Volume 0" is not used in IHE technical frameworks. It should be replaced with "General" or "General Introduction".

Proposed Change

Remove all "hard coded" use of "Volume 0"; update the bottom navigation bar to replace "Volume 0" with "General"

Section Number

TF-2 section B.2

Priority

High: Important issue where there is major issue to be resolved. Requires discussion and debate.*

Issue

REVIEWER QUESTION: Issue: HL7 Local Time vs. SDC UTC time: SDC requires that all timestamps are in UTC. The time zone
is optional. In HL7 V2 all timestamps are local time and the time zone is optional as well.
Do Device Observation Consumer (DOC) and Alarm Manager (AM) expect the gateway to convert UTC to local
time?

Proposed Change

@MartinKasp answered: Yes, in my opinion, this would be the task of the gateway. Assuming that the correct UTC times are given in SDC and the correct local times are given in HL7, the only thing the gateway needs to know is the local time zone to convert the values correctly, right?
@PeterKranich commented: The problem is that a gateway could be located elsewhere in the world - a data center in Kansas and the PoC device in Florida and California. When the device is not able to provide the time zone, gateways configured for different timezones must be configured in the data center.
@d-gregorczyk , @riechkathrin , @PeterKranich and @AnnaFeiler agreed that the provider shall provide the time zone. Without time zone, gateway export will not be supported.

These two articles will be updated as the "transition" to AsciiDoc is completed, and the editors both learn about the source language + how to craft the SDPi supplement content using AsciiDoc. This issue includes the following tasks ...

• IHE/sdpi-fhir#75
• #39
• IHE/sdpi-fhir#77

Section Number

TF-2 Sections B.4

Priority

Martins list of comments

Issue

Currently, the ACM and DEC gateway section fully describe the mapping requirements without jumping back and forth to other sections in the document. However, the issue is that common requirements are duplicated with the same requirement id in both section which leds to some problems. So, we need to move the common requirment to the common gateway section.

Proposed Change

We need to move the common requirment to the common gateway section.

Section Number

Entire document

Priority

Low to high ;-)

Issue

Some requirements are context-sensitive to the chapter/annex the belong to. Thus, when you only get rie requirement, it can be misleading. For example: R1002 forbids UPD connections (except for ad-hoc discovery). However, this is only valid for the MDPWS binding. Thus, you have to know that R1002 is part of appendix A to understand it. The requirement will not apply for, e.g., BICPES-over-CoAP.

Proposed Change

Intended fix: In general, we should aim for requirements that can be interpreted unambiguously without context or that the context is always clear. Options: Rephrase requirements; introduce requirement number prefixes that clarify the context unambiguously.

Section Number

All source files

Priority

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

Issue

Need to finalize the version information for all the source files related to the SDPi 1.0 Public Comment version.

Proposed Change

Tag the final version of the repository that is used for the SDPi 1.0 Public Comment version. Update the version history.

From @MaryLJ : A wiki article discussing tagging a release is at Authoring Long Form Supplements and White Papers - Github Repository Tagging.

Note: The article does specifically define what the numbering should be but I will be updating it to indicate numbering should be what we looked at yesterday (e.g., 1.0.0). We have been inconsistent in the use of “V” in front of the number but more often than not, we did not use it, so going forward, we will not include the “v”.

Section Number

TF-2 Sections B.4

Priority

Martin's list

Issue 1

We agreed in the Alert-PKP working group that we need a unique alert event identifier from the alert source. This shall be a GUID. OBR requirements have to be updated accordingly.

Some background information on the unique identifier from the current APKP draft:
○ Extension pm:AlertConditionState/@apkp:AlertOccurrenceIdentifier --> type = GUID
○ Alert Provider: When AlertConditionState/@presence is changed to true , set @apkp:AlertOccurrenceIdentifier in the same State version.
○ Extension pm:AlertConditionState/@apkp:OnsetStateVersion
○ Alert Provider: When AlertConditionState/@presence is changed to true, set @apkp:OnsetStateVersion to the current State version in the same State version.
○ Alert Provider: While AlertConditionState/@presence does not change to true, @apkp:AlertOccurrenceIdentifier and @apkp:OnsetStateVersion SHALL NOT be removed or modified.

Issue 2

Table TF-2:B.4.4.7.8-128. Alert Types Value Set Mapping need to be updated due to the APKP decision: advisories are no longer limited to @kind = Other, but to @priority / @ActualPriority = None

Section Number

10.1.1

Priority

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Issue

• The word "in" is repeated in the first sentence of the second paragraph in Section 10.1.1
• Also in the sentence, the wording ...in the Section 3 volume... seems not quite right
• In the 3rd paragraph, the wording "Figure TF-1:10.1.1-1 illustrates a typical (not comprehensive) exchange scenarios between SDPi-P actors" should be updated to either "typical" (remove the "a" in front of typical) if this is meant to be plural or change "scenarios" to "scenario" if intended to be singular.

Proposed Change

Remove the repeated word and update wording as suggested. Thanks.

See also: Topic: What is a Smart Alert System?

From SDPi 1.0 Workshop: Content is ready and will now be integrated by Todd to volume 3.

Section Number

Section 9.5

Priority

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

Issue

General Intro section 9.5 should be 9.1.5

Proposed Change

Change 9.5 back to 9.1.5. If needed insert 9.1 Copyright of Base Standards

Although the SDPi 1.0 approach for the IHE TF Open / Closed issues tables, integrating with Github issues and back to Topics of Interest (confluence) discussions, still seems outdated and should be considered how to optimize for current development methods and tooling support.

This issue is a follow-on to IHE/sdpi-fhir#232, which includes the heart felt comment from @d-gregorczyk :

To be honest, I do not see a reason to have this chapter as it is - at least I don't feel like maintaining this tremendously growing list and moving issues back and forth. Is this explicitly required by IHE? I'd rather recommend to add a changelog list to the document or to a seperate changelog.md file similar to how it is done here: https://gitlab.com/sdc-suite/sdc-ri/-/blob/develop/CHANGELOG.md ; based on: https://keepachangelog.com/en/1.0.0/

This allows for readers of the spec to track added, deleted and modified chapters throughout the document's lifecycle. A Github reference number can be added to changelog entries for linkage to the actual github issues - where the details should reside. Changelog entries should not be longer than a single sentence (see also the linked changelog above).

Moreover, for any 1.0 of something there is no need to have a changelog - it's the baseline document. Only if we begin changing document 1.0 because of defects, change requests or obsoletions, we should gradually fill in the space of the chaneglog.

Strong disagree? Any thoughts?

Section Number

B.3.4.2.6
B.4.4.2.6

Priority

Medium/High

Issue

The informative text below R8107 already describes the problem fairly well: Mapping from sex in 11073 to administrative gender in HL7 is wrong and shall not be done. The last sentence in the paragraph (i.e., it shall be mapped even though it is wrong) lacks justification.

Proposed Change

Option 3 (as described in the note above R8107).

• R8107 becomes conditional, i.e. only when administrative gender information is present in SDC.
• Another requirement for SFCU is introduced.
• Table 29 is amended according to "Option 3".
• Table 30 is duplicated (for sex and gender) and amended. (On a separate note: a directional mapping from "Ambiguous" to "Unspecified" is reasonable, but the reverse direction from Unspecified to Ambiguous is not safe, because HL7/Ambiguous is a proper subset of SDC/Unspecified.)

Section Number

TF-1 & TF-2

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

Per the SDPi Friday discussion 03.02.2023, Discussion section 4.b.iv.2.f, it was agreed that the Trial Implementation version of the SDPi 1.0 supplement should reflect the current draft content of the 11073-10702 Alert PKP standard; however, this can be done during the 30-day public comment period.

Proposed Change

Update the SDPi 1.0 Public Comment version to reflect the current draft content of the 11073-10702 Alert PKP standard.

Section Number

This relates to @MartinKasp comment in IHE/sdpi-fhir#288. B.3.4.4.4 PV1-19 Visit Number

Priority

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

Issue

The issue surfaced in the IHE HL7 V2 gateway section but is a general issue about how to deal with patient encounters (alias visits).

Proposed Change

R8114 states:
"A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PV1-19 field to the patient’s visit identifier.
If the SDC patient identifier element pm:PatientContextState/pm:Identification contains more than one patient
identifier, only the unique identifier assigned to the patient’s visit is mapped according to the Table TF-2:B.3.4.4.4-75. PV1-
19 Visit Number Mapping table.
When there is no unique visit identifier assigned to the patient’s visit, the field is left empty."

@MartinKasp recommended to use the MDIB WorkflowContext for this concept, but from the BICEPS definition it is not clear how to use it in real clinical workflows. FHIR has a good decription for the Encounter conecpt (http://hl7.org/fhir/administration-module.html). The WorkflowContext has a WorkflowDetail element which has elements for patient, AssignedLocation, VisitNumber, etc. but how does this relate to the existing PatientContextState and LocationContextState?
Use case need to be defined and mapped to the SDPi requirements for the WorkflowContext.

This also relates to
R8115
"A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PV1-44 field to the patient’s admission date/time.
The SDC data model does not support the concept of an admission date/time. There are also different types of admissions;
e. g. hospital admission, care unit admission, etc.
This said, it is up to the SOMDS DEC Gateway / SOMDS ACM Gateway to figure out the admission date/time to be set in the
PV1-44 field. If the gateway is not able to determine the admission date/time, the field is left empty."
@MartinKasp : Suggested covering the admission date/time using the workflow context. If we do this, SDPi needs to define how to model this in SDC.

Table 35 also needs to be considered
According to table 35 there is more than one valid identifier type code for the visit number. R8114 says only the unique identifier assigned to the patient’s visit is mapped.
@riechkathrin commented: From my experience, limit the visit identifier only to the Visit Number (VN) is not appropriate. Often the Account Number (AN) is used for identifying a visit. Some EMRs also have their own visit identification types e. g. Cerner uses FIN for the visit/encounter identification (https://fhir.cerner.com/millennium/dstu2/encounters/encounter/).