1. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 1 IEEE 11073 20101 Application Profile – Association Control Function Dan Smith, dssmith@westhealth.orgdssmith@westhealth.org Harry McKee, hlmckee@westhealth.orghlmckee@westhealth.org

2. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 2 Agenda Scope Assumptions Approach Sample Advantages Disadvantages Removed fields Issues Next Steps

3. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 3 Scope Summary: Define compatible set of ASN.1 messages for both 20101 & 20601 Allow all data to be communicated using the MDER Encoding Rules Support the existence of multiple-protocol managers that support both POC & PHD devices

4. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 4 Assumptions The CNS (20401) proposal will identify unique network paths (ie. TCP port) for each standard (classic 20101, 20601 & proposed harmonized) Existing PHD devices properly verify the fields in existing 20601 messages (ie data- proto-id) before using the data received

5. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 5 General Approach Adopt the 20601 approach to messaging Move away from ACSE Standard Add new data fields to the 20601 structures to capture needed 20101 data Implement a NULL Presentation & Session Layer – aka remove their functionality from association.

6. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 6 AARQ ASN.1 AarqApdu ::= SEQUENCE { assoc-version AssociationVersion, data-proto-list DataProtoList } AssociationVersion ::= BITS-32 { assoc-version1 (0) -- association protocol version 1 } DataProtoList ::= SEQUENCE OF DataProto DataProto ::= SEQUENCE { data-proto-id DataProtoId, data-proto-info ANY DEFINED BY data-proto-id } DataProtoId ::= INT-U16 { data-proto-id-empty (0), data-proto-id-20101 (20101), data-proto-id-20601 (20601), data-proto-id-external (65535) } MdapAssociationInformation ::= SEQUENCE { user-info MDSEUserInfo } MDSEUserInfo ::= SEQUENCE { protocolVersion ProtocolVersion, nomenclatureVersion NomenclatureVersion, functionalUnits FunctionalUnits, systemType SystemType, startupMode StartupMode, optionList AttributeList, supportedAProfiles AttributeList }

7. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 7 Advantages to this approach POC & PHD devices will share the same messaging structure at a high level All message data is encoded using MDER POC-specific data is captured with the new MDAPAssociationInformation field Simplifies Implementation Allows managers to more easily support multiple association styles*. * See disadvantage page

8. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 8 Disadvantages to this approach May require separate port for classic ACSE messages vs. new style messages due to overlap between MDAP-XT session layer & PHD-defined AARQ (0xe2) Moves away from standardized association towards a custom solution for medical devices

9. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 9 Removed Fields Proposal removes application-context-name (AARQ/AARE) AARQ-apdu ::= [APPLICATION 0] IMPLICIT SEQUENCE { protocol-version [0] IMPLICIT BIT STRING {version1(0)} DEFAULT {version1}, application-context-name [1] Application-context-name, user-information [30] IMPLICIT Association-information }

10. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 10 Removed Fields Proposal removes the Associate-source-diagnostic field AARE-apdu ::= [APPLICATION 1] IMPLICIT SEQUENCE { protocol-version [0] IMPLICIT BIT STRING {version1(0)} DEFAULT {version1}, application-context-name [1] Application-context-name, result [2] Associate-result, Result-source-diagnostic [3] Associate-source-diagnostic, user-information [30] IMPLICIT Association-information } Associate-source-diagnostic ::= CHOICE { acse-service-user [1] INTEGER { null(0), no-reason-given(1), application-context-name-not-supported (2), }, acse-service-provider [2] INTEGER { null(0), no-reason-given(1), no-common-acse-version(2) }

11. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 11 Removed Fields POC & PHD aborts are slightly different ABRT-apdu ::= [APPLICATION 4] IMPLICIT SEQUENCE { abort-source [0] IMPLICIT ABRT-source } ABRT-source ::= INTEGER { acse-service-user(0), acse-service-provider(1) } AbrtApdu ::= SEQUENCE { reason Abort-reason } Abort-reason ::= INT-U16 { undefined(0), buffer-overflow(1), response-timeout(2), configuration-timeout(3) }

12. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 12 Open Issues Is there a need to support other encoding rules (such as BER?) MDER-only makes implementations easier Must be able to encode all data properly Must account for all applications of this protocol Is anything lost by being MDER-only?

13. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 13 Open Issues Adding in a fast-association component Match PHD's config-id based fast association feature Reduce amount of data transferred during connection process POC order of association (initial message sent from manager) makes things more difficult Possibly could be solved with a second AARQ message

14. IEEE 11073 20101 ACSE_rev02.ppt SLIDE 14 Next Steps Write up a full proposal Discuss it on a periodic web-ex Finalize proposal & vote – hopefully at F2F in Jan.