Activity for SDC
-
Lukas Deichmann modified ticket #413
SafetyClassification responsibility
-
SafetyClassification responsibility
-
wsd:Scope can not reflect multiple MDSs (and/or VMDs) with the same type
-
wsd:Scope can not reflect multiple MDSs (and/or VMDs) with the same type
-
Philipp Staeck created ticket #75
wsd:Scope can not reflect multiple MDSs (and/or VMDs) with the same type
-
Consider translations for scope matching
-
Stefan Schlichting created ticket #30
Add means to identify a consumer in RR & Eventing
-
Björn Andersen modified ticket #412
Table 14 Corrigendum incorrect names
-
B.324 revise/remove PatientType
-
How to provide a display range
-
See discussion of UI information to be transmitted in ticket [#193] etc.
-
Supposed inconsistancy between SystemErrorReport/ReportPart/ErrorInfo and OperationInvokedReport/ReportPart/InfocationInfo/InvocationErrorMessage
-
See also [#394].
-
Ticket moved from /p/opensdc/ieee11073-10207/408/
-
multiple invocation states within one report
-
Add extension that allows to classify errors
-
C.77 OperationInvokedReportPart and multi-state updates
-
remodelling of MetricCategory
-
SystemErrorReport/ReportPart/ErrorInfo limited to one occurrence
-
R0126 and Figure 13
-
Normative reference to latest version of 10101
-
Verify normative references
-
Battery objects on VMDs
-
Consider removing / explaining InvocationRequested and InvocationRequired in detail
-
Depends on the outcome of [#100].
-
Add further explanations to InvocationRequested and InvocationRequired
-
B.439 MDS operating mode: service vs. maintenance
-
Absolute verbiage
-
Commas inside quotes change semantics
-
Remove Clause 6
-
See [#383] etc.
-
Clarify scope of clause 6
-
To be solved by removal of clause 6 and related definitions, see [#383].
-
Typo in Clause 6.3.1 AlertSignalDescritpor -> AlertSignalDescriptor
-
To be solved by removal of clause 6, see [#383].
-
Remove Clause 6
-
Align clause 6 with APKP
-
Remove clause 6. Alarm distribution will be covered by APKP.
-
Implied values
-
Keep previous metric value during ongoing measurements
-
Clean solution would be to remove Ong from the value set and to create a separate attribute, because it simply prohibits the provision of a value (see R0235) rather than describing the value's validity. (Possibly do the same for Calib?)
-
Add information about Multi-MDS Modelling
-
This ticket discusses three proposals. To add a recommendation is not breaking backward compatibility. Generic relations: [#411] To add an optional attribute group is not breaking backward compatibility. (We'd need to find a good place for these attributes. All information above MDS level is static.)
-
(Merge into one attribute that lists all possible values (escalated and deescalated) that the priority can assume? Would be PROVIDER-breaking, too.)
-
Express cannot escalate/deescalate
-
Also consider not to inherit from pm:AlertConditionPriority. (What to select if a condition can escalate to, e.g., medium or high priority?)
-
R0060: hazardous situation cannot be avoided
-
Remove R0060, split into xCPKP ticket: [p11073-10703:#12]
-
replacement requirements for BICEPS:R0060
-
replacement requirements for R0600
-
Remove R0056
-
DateAndTime attribute
-
Remove the attribute DateAndTime from the data model.
-
pm:ReferencedVersion shall not inherit from pm:VersionCounter
-
D.3 Clarify that InstanceId changes have similar effects as the SequenceId changes
-
SequenceId can not replace InstanceId
-
D.3 Clarify that InstanceId changes have similar effects as the SequenceId changes
-
revise LocationDetail
-
B.15 add human-readable form to pm:Validator?
-
GetContainmentTreeResponse result set is of limited use
-
GetContainmentTreeResponse result set is of limited use
-
new annex: mapping from ISO 80601-2-xx and IEC 60601-2-yy
-
CauseInfo: descriptor vs. state
-
Need for Alert Grouping ?!
-
@martinuro: Is this ticket still relevant?
-
Need for Technical Ranges / Allowed Values in ActivateOperationDescriptor/Argument ?!
-
PersonReference in OperatorContext
-
Appears to have been fixed nearly a decade ago.
-
Accuracy class of measurements
-
The use case is adequately covered by SafetyClassification. Setting it to "Inf" indicates that there is no (medical) intended use for a component or Metric.
-
B.429: ComponentActivation value set extension
-
Table 14 Corrigendum incorrect names
-
TR0199 phrasing
-
TR0199 phrasing
-
Automatic UI generation: order of CTEs, scaling, labels, etc.
-
Ticket moved from /p/opensdc/ieee11073-10207/121/
-
Allow restrospective annotations for RealTimeSampleArrayMetricState
-
SDPi?
-
Future frames are out of scope at this point in time.
-
Add an extension to indicate OperatingHours/Cycles until next calibration
-
Sounds a lot like SDPi.
-
Sounds alot like SDPi.
-
Practical examples of BICEPS model element instances
-
Guidelines on Stucturing and MDIB
-
To what extent should we really describe the DevSpec topic in BICEPS?
-
Allow for type ref in Get services
-
Ticket moved from /p/opensdc/ieee11073-10207/166/
-
B.128 Multiple SystemSignalActivation with same Manifestation
-
Solved in Corrigenda.
-
B.309 includes SHOULD requirement, but no entry in conformance table exists
-
B.141 includes SHOULD requirement, but no entry in conformance table exists
-
B.46 includes SHOULD requirement, but no entry in conformance table exists
-
generic relations (not only in Metrics)
-
Optimize usage of DescriptionModificationReport parent descriptor
-
MdState/@StateVersion not incremented for added and removed context states
-
Solved as part of [#18].
-
Insertion and deletion of context states unclear
-
If we introduce a new service, we could technically make this only provider-breaking.
-
B.442 MetricCategory --> which type for characteristics of a device or device appliances?
-
See also: [#161]
1 >
