1 / 14

IEEE 11073 20101 Application Profile – Association Control Function

IEEE 11073 20101 Application Profile – Association Control Function. Dan Smith, dssmith@westhealth.org Harry McKee, hlmckee@westhealth.org. Agenda. Scope Assumptions Approach Sample Advantages Disadvantages Removed fields Issues Next Steps. Scope Summary:.

brilliant
Download Presentation

IEEE 11073 20101 Application Profile – Association Control Function

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • Scope • Assumptions • Approach • Sample • Advantages • Disadvantages • Removed fields • Issues • Next Steps

  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. 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. 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. AARQ ASN.1 MdapAssociationInformation ::= SEQUENCE { user-info MDSEUserInfo } MDSEUserInfo ::= SEQUENCE { protocolVersion ProtocolVersion, nomenclatureVersion NomenclatureVersion, functionalUnits FunctionalUnits, systemType SystemType, startupMode StartupMode, optionList AttributeList, supportedAProfiles AttributeList } 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) }

  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. 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. 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. 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. 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. 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. 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. Next Steps • Write up a full proposal • Discuss it on a periodic web-ex • Finalize proposal & vote – hopefully at F2F in Jan.

More Related