【AS澳大利亚标准】AS TR 2965 Harmonisation of HD and EI data types across AS 4700.X Standards and associated Handbooks

《【AS澳大利亚标准】AS TR 2965 Harmonisation of HD and EI data types across AS 4700.X Standards and associated Handbooks》由会员分享，可在线阅读，更多相关《【AS澳大利亚标准】AS TR 2965 Harmonisation of HD and EI data types across AS 4700.X Standards and associated Handbooks（33页珍藏版）》请在装配图网上搜索。

1、TR 29652007Accessed by UNIVERSITY OF SOUTH AUSTRALIA on 04 Apr 2008TR 29652007Technical ReportHarmonisation of HD and EI data types across AS 4700.X Standards and associated HandbooksThis Australian Technical Report was prepared by Committee IT-014, Health Informatics. It was approved on behalf of t

2、he Council of Standards Australia on 19 October 2007.This Technical Report was published on 23 November 2007.The following are represented on Committee IT-014:Australian and New Zealand College of AnaesthetistsAustralian Association of Pathology PracticesAustralian Department of Health and AgeingAus

3、tralian Electrical and Electronic Manufacturers AssociationAustralian Information Industry AssociationAustralian Institute of Health & WelfareAustralian Institute of RadiographyAustralian Private Hospitals AssociationCentral Queensland UniversityConsumers Federation of AustraliaConsumers Health

4、Forum of AustraliaCSIRO e-Health Research CentreDepartment of Health (South Australia)Department of Health Western AustraliaDepartment of Human Services, VictoriaEngineers AustraliaHealth Informatics Society of AustraliaHealth Information Management Association of AustraliaHL7 AustraliaMedical Indus

5、try Association of AustraliaMedical Software Industry AssociationNational Health Information Management Principal CommitteeNSW Health DepartmentPharmacy Guild of AustraliaPharmaceutical Society of AustraliaQueensland HealthRoyal Australian and New Zealand College of RadiologistsRoyal Australian Coll

6、ege of General PractitionersRoyal Australian College of Medical AdministratorsRoyal College of Nursing, AustraliaRoyal College of Pathologists of AustralasiaUniversity of SydneyAdditional Interests:Cerner CorporationCollaborative Centre for eHealthDH4HCNLa Trobe UniversityMcCauley SoftwareMedical Ob

7、jectsMichael Legg & AssociatesAccessed by UNIVERSITY OF SOUTH AUSTRALIA on 04 Apr 2008Ocean InformaticsPen Computer SystemsStandards Australia wishes to acknowledge the participation of the expert individuals that contributed to the development of this Standard through their representation on th

8、e Committee.Keeping Standards up-to-dateAustralian Standards® are living documents that reflect progress in science, technology and systems. To maintain their currency, all Standards are periodically reviewed, and new editions are published. Between editions, amendments may be issued.Standards

9、may also be withdrawn. It is important that readers assure themselves they are using a current Standard, which should include any amendments that may have been published since the Standard was published.Detailed information about Australian Standards, drafts, amendments and new projects can be found

10、 by visiting www.standards.org.auThe Standard is downloaded from Standard SharingStandards Australia welcomes suggestions for improvements, and encourages readers to notify us immediately of any apparent inaccuracies or ambiguities. Contact us via email at mailstandards.org.au, or write to Standards

11、 Australia, GPO Box 476, Sydney, NSW 2001.TR 29652007Accessed by UNIVERSITY OF SOUTH AUSTRALIA on 04 Apr 2008Technical ReportHarmonisation of HD and EI data types across AS 4700.X Standards and associated HandbooksFirst published as TR 29652007.COPYRIGHT© Standards AustraliaAll rights are reser

12、ved. No part of this work may be reproduced or copied in any form or by any means, electronic or mechanical, including photocopying, without the written permission of the publisher.Published by Standards Australia GPO Box 476, Sydney, NSW 2001, AustraliaISBN 0 7337 8465 83TR 29652007PREFACEThis Tech

13、nical Report was prepared by the IT-014-06 Messaging subcommittee under direction from the Standards Australia Committee IT-014, Health Informatics in response to the Australian Governments objectives for National Standards and related Standards materials within the health sector.This Technical Repo

14、rt identifies HD and EI data types across AS 4700.X Standards and associated handbooks resulting in the publication of amendments to Health Informatics publications where appropriate. This will correct any inconsistencies with the existing Standards or handbooks.The mission of IT-014-06 is to invest

15、igate and make recommendations to IT-014 on strategic directions in messaging.One of the pillars of e-health is the ability to identify the source, target and authoring organisations involved in messaging. Without robust identifiers clinical data will not reliably reach the intended recipient or org

16、anisation. This has both reliability and privacy implications and it is important that all parties have a good understanding of the identifiers contained in HL7 messages.The issues also include identifying the authoring and sending organisation as well as specifying the recipient organisation. Withi

17、n messages there are several levels of identifiers, with provider identifiers (XCN ID numbers) used to identify individuals and Hierarchic Designators (HD) used to identify organisations. All providers belong to an organisation, even if it is a single doctor practice. HDs can also identify other obj

18、ects such as software applications.Individual reports are also identified using the Entity Identifier (EI) type which is a combination of a string identifier and a Hierarchic Designator (HD). The string identifier should be unique over time, within the producing organisation. It may not be unique be

19、tween institutions however.Despite the presence of these types in most messages there is a lot of confusion on how to use them and how to create one when needed.The Standard is downloaded from Standard SharingAccessed by UNIVERSITY OF SOUTH AUSTRALIA on 04 Apr 2008Standards Australia wishes to thank

20、 the Department of Health and Ageing for their continued financial support in helping us to develop this technical report.Accessed by UNIVERSITY OF SOUTH AUSTRALIA on 04 Apr 2008CONTENTSPage1SCOPE AND GENERAL . 42EXPLANATION OF THE DATA TYPES . 53USING HIERARCHIC DESIGNATOR VALUES IN OTHER DATA TYPE

21、S . 74EXAMPLES OF HD DATA TYPES . 95EXAMPLE OF EI DATA TYPE . 106TABLES OF HD AND EI DATA TYPES . 107AUSTRALIAN IMPLEMENTATION OF HL7 HANDBOOKS . 2827TR 29652007The Standard is downloaded from Standard SharingSTANDARDS AUSTRALIATechnical ReportHarmonisation of HD and EI data types across AS 4700.X S

22、tandards and associated Handbooks1 SCOPE AND GENERAL1.1 ScopeThis Technical Report identifies Hierarchic Designator (HD) and Entity Identifier (EI) data types across the AS 4700.X range of Standards and associated Handbooks. It investigates the harmonisation of HD and EI data types including those H

23、D data types incorporated in other data types, such as XCN (Extended Composite ID number).This Technical Report includes tables of the HD and EI data types used in the AS 4700.X Australian implementation of HL7 V2 publications. Specific examples and, in some cases usage notes are given for each inst

24、ance of HD or EI.1.2 PurposeThe purpose of this Technical Report is to harmonise the use of Hierarchic Designator (HD) and Entity Identifiers (EI) data types across the AS 4700.X Standards and associated Handbooks.1.3 BenefitsUnderstanding the purpose of Hierarchic designators and Entity Identifiers

25、 and the options available for their generation and use is vital information for implementers, policy makers and anyone who wishes to reliably identify organisations, software components or provider groups. Any national identifier scheme should be designed to work well with this vital structural ele

26、ment of HL7 messaging.1.4 Target usersAccessed by UNIVERSITY OF SOUTH AUSTRALIA on 04 Apr 2008This Technical Report has been written specifically for implementers, policy makers and anyone who wishes to reliably identify organisations, software components or provider groups.1.5 Referenced documentsA

27、S4700Implementation of Health Level Seven (HL7) Version 2.3.14700.12001Part 1: Patient administration4700.22004Part 2: Pathology orders and results4700.52002Part 5: Immunisation messages4700.62004Part 6: Referral and discharge summary4700.72005Part 7: Diagnostic imaging orders and results4700Impleme

28、ntation of Health Level Seven (HL7) Version 2.44700.12005Part 1: Patient administration4700.22007Part 2: Pathology and medical imaging (Diagnostics)4700.32005Part 3: Electronic messages for exchange of information on drug prescription4700.52005Part 5: Immunisation messages4700.62006Part 6: Referral,

29、 discharge and health record messaging© Standards Australiawww.standards.org.auAccessed by UNIVERSITY OF SOUTH AUSTRALIA on 04 Apr 2008AS4700Implementation of Health Level Seven (HL7) Version 2.54700.12006Part 1: Patient administration4700.32007Part 3: Electronic messages for exchange of inform

30、ation on drug prescription4700.52007Part 5: Immunisation messages4700.62007Part 6: Referral, discharge and health record messagingAS/NZS4700Implementation of Health Level Seven (HL7) Version 2.3.14700.3:2002Part 3: Electronic messages for exchange of information on drug prescriptionHB2622007Guidelin

31、es for pathology messaging between pathology providers and health service providers2352007Implementers guideline for HL7 referral discharge and health record messaging2 EXPLANATION OF THE DATA TYPES2.1 Hierarchic designatorComponents: <namespace ID (IS)> <universal ID (ST)> <universal

32、 ID type (ID)>The Hierarchic Designator is designed to be a more powerful and more general replacement for the application identifier of HL7 versions 2.1 and 2.2. It adds two additional components, the <universal ID> and the <universal ID type> to the former application ID (which is r

33、enamed more generically to be the namespace ID) The basic definition of the HD is that it identifies an (administrative, system or application or other) entity that has responsibility for managing or assigning a defined set of instance identifiers (such as placer or filler number, patient identifier

34、s, provider identifiers, etc.). This entity could be a particular health care application such as a registration system that assigns patient identifiers, a governmental entity such as a licensing authority that assigns professional identifiers or drivers license numbers, or a facility where such ide

35、ntifiers are assigned.The term Namespace ID is confusing. It does not relate to the classic Namespace but is a textual identifier for an entity. It is often related to the common human name for an object e.g. Queensland Medical Laboratories or QML. It is similar to the Lab name used in PIT Messages.

36、The assigning authority defined by the HD is similar in its role to the coding system (and version) part of the coded element data types, both identify a set of more discrete instance identifiers. The difference is that the set of HD-defined discrete instances contain identifiers of real-world thing

37、s such as patient or clinical orders, while the coded element-defined set of discrete instances contains concept identifiers (codes). The HD is designed to be used either as a locally managed identifier (with only the <namespace ID> valued) or a formulised unique identifier, a UID (with both &

38、lt;universal ID> and <universal ID type> valued). Syntactically, the HD is a group of two identifiers for the same entity: the locally managed identifier is provided in the first component (namespace ID); the formalised unique identifier is provided in the second component (Universal ID) an

39、d the Universal ID formalism is provided in the third component (Universal ID type).Universal ID type does not relate to Namespace ID.The HD is used in fields that in earlier versions of HL7 used the IS data type. Thus, a single component HD (only the first component valued) will look like a simple

40、IS data type for older systems expecting a single component in the place of the HD data type.The Standard is downloaded from Standard SharingIf namespace IDs are not unique, problems correctly interpreting the entity being identified can occur. Therefore when adopting a namespace ID, the communicati

41、on coverage of the message and its identified entities in the current context and in downstream communication (message content reused in further communication, which may have wider coverage such as hospital laboratory reports provided within discharge summaries) must be considered. It is recommended

42、 that namespace ID be at least unique within Australia. Consideration is being given to determine the suitable organisation(s) to maintain a registry of namespace IDs.If the first component for the HD data type is present, the second and third components are optional. If the third component is prese

43、nt, then the second must also be present (although in this case the first is optional). The second and third components must either both be valued (both non-null), or both be not valued (both null). The universal ID value is unique within the scope of the universal ID type based on the formalism of

44、the universal ID type.When all three components of the HD are valued, the entity identified by the first component must be the same as the entity identified by the second and third components together.2.2 Components of the hierarchic designator2.2.1 Namespace ID (IS)User-defined table 0300Namespace

45、ID is used as the HL7 identifier for the user-defined table of values for this component. See Table 2.2.2.2 Universal ID (ST)The HDs second component, <universal ID (UID), is a string formatted according to the scheme defined by the third component, <universal ID type> (UID type). The UID i

46、s intended to be unique over time within the UID type. It is rigorously defined. Each UID must belong to one of the specifically enumerated schemes for constructing UIDs (defined by the UID type). The UID (second component) must follow the syntactic rules of the particular universal identifier schem

47、e (defined by the third component). Note that these syntactic rules are not defined within HL7 but are defined by the rules of the particular universal identifier scheme (defined by the third component).2.2.3 Universal ID type (ID)Accessed by UNIVERSITY OF SOUTH AUSTRALIA on 04 Apr 2008The third com

48、ponent governs the interpretation of the second component of the HD. If the third component is a known UID (refer to HL7 table 0301 Universal ID type for valid values), then the second component is a universal ID of that type. Table 1A describes the Universal ID types in HL7 table 0301 and Table 1B

49、describes the additional Universal ID types used in Australia.Accessed by UNIVERSITY OF SOUTH AUSTRALIA on 04 Apr 2008TABLE 1AHL7 TABLE 0301: UNIVERSAL ID TYPEValueDescriptionDNSAn Internet dotted name. Either in ASCII or as integerGUIDSame as UUIDHCDThe CEN Healthcare Coding Scheme Designator. (Ide

50、ntifiers used in DICOM follow this assignment scheme.)HL7Reserved for future HL7 registration schemesISOAn International Organisation for Standardisation Object IdentifierL, M, NThese are reserved for locally defined coding schemesRandomUsually a base64 encoded string of random bits.The uniqueness d

51、epends on the length of the bits. Mail systems often generate ASCII string unique names, from a combination of random bits and system names. Obviously, such identifiers will not be constrained to the base64 character set.UUIDThe DCE Universal Unique IdentifierX400An X.400 MHS format identifierX500An

52、 X.500 directory nameNOTE: X400, X500 and DNS are not technically universally valid for all time. Names can be de- registered from an existing user and registered to a new user.TABLE 1BADDITIONAL AUSTRALIAN UNIVERSAL ID TYPEValue DescriptionAUSNATANATA Laboratory NumberTABLE 2USER DEFINED TABLE 0300

53、: AUSTRALIAN NAMESPACE IDValueDescriptionAUSNATANATA Laboratory NumberAUSHICAustralian Medicare NumberAUSHICPRAustralian Medicare Provider Number3 USING HIERARCHIC DESIGNATOR VALUES IN OTHER DATA TYPES3.1 GeneralIn the case where a HD identifies an entity that assigns/creates instance identifiers su

54、ch as a particular patient registration system, it defines an assigning authority. In the case where a HD identifies a location where instance identifiers are given out (although they may be created by another entity at another location) such as a particular department of motor vehicles office locat

55、ion, it defines an assigning facility. These two different uses of the HD appear in many of the extended data types. An example is the XCN type used to identify providers. The ID Number, which is usually the provider number in Australia is assigned by Medicare Australia and is identified by the HD N

56、amespace of AUSHICPR.To explain this the XCN definition in HL7 V2.3.1 will be used as an example.The Standard is downloaded from Standard Sharing3.2 XCN extended composite ID number and name for personsComponents:<ID number (ST)> <family name (ST) > & < last_name_prefix (ST)> &

57、lt;given name (ST)><middle initial or name (ST)> <suffix (e.g. JR or III) (ST)> <prefix (e.g. DR) (ST)> <degree (e.g. MD) (IS)> <source table (IS)> <assigning authority (HD)> <name type code(ID)> <identifier check digit (ST)> <code identifying th

58、e check digit scheme employed (ID )> <identifier type code (IS)> <assigning facility(HD)> <name representation code(ID)>An example of an a Australian XCN would be:0072634LMITCHELLKEITHJDRAUSHICPRLUPINIn this case the HD Component consists of only the Namespace which is highlight

59、ed in bold. There is no assigning facility defined as its only done in one place.Another example of an XCN where a Medicare Australia provider number is not used: JD455600041DAVISONJAREDMRMedical-Objects&7C3E3682-91F6-11D2-8F2C-444553540000&GUIDLUPINAccessed by UNIVERSITY OF SOUTH AUSTRALIA

60、on 04 Apr 2008In this case all 3 sub-components are valued. The HD value is highlighted in bold. Again the assigning facility is not valued.Another example of the use of HD values is in entity identifiers.3.3 EI entity identifierComponents:<entity identifier (ST)> <namespace ID (IS)> <universal ID (ST)>