1、Mai 2006 Normenausschuss Medizin (NAMed) im DINPreisgruppe 13DIN Deutsches Institut fr Normung e.V. Jede Art der Vervielfltigung, auch auszugsweise, nur mit Genehmigung des DIN Deutsches Institut fr Normung e.V., Berlin, gestattet.ICS 35.240.80!,f3Z“9671655www.din.deDVornormDIN CEN/TS 14822-4Medizin
2、ische Informatik Allgemein verwendbare Informationskomponenten Teil 4: Nachrichtendateikpfe;Englische Fassung CEN/TS 14822-4:2005Health informatics General purpose information components Part 4: Message headers;English version CEN/TS 14822-4:2005Informatique de sant Unit dinformation dans les messag
3、es Partie 4: En-ttes de message;Version anglaise CEN/TS 14822-4:2005Alleinverkauf der Normen durch Beuth Verlag GmbH, 10772 Berlin www.beuth.deGesamtumfang 21 SeitenDIN CEN/TS 14822-4:2006-05 2 Nationales Vorwort Diese Vornorm enthlt unter Bercksichtigung des Prsidialbeschlusses 13/1983 den englisch
4、en Originaltext des Dokuments CEN/TS 14822-4:2005. Diese Technische Spezifikation wurde in der WG I Information Models des CEN/TC 251 Medizinische Informatik erarbeitet, dessen Sekretariat von NEN (Niederlande) gehalten wird. Der Arbeitsausschuss NA 063-07-02 AA Interoperabilitt des Fachbereichs 07
5、Medizinische Informatik des Normenausschusses Medizin im DIN hat an der Erarbeitung mitgewirkt. Eine Vornorm ist das Ergebnis einer Normungsarbeit, das wegen bestimmter Vorbehalte zum Inhalt oder wegen des gegenber einer Norm abweichenden Aufstellungsverfahrens vom DIN noch nicht als Norm herausgege
6、ben wird. Erfahrungen mit dieser Vornorm sind erbeten vorzugsweise als Datei per E-Mail an nameddin.de in Form einer Tabelle. Die Vorlage dieser Tabelle kann im Internet unter http:/www.din.de/stellungnahme abgerufen werden; oder in Papierform an den Normenausschuss Medizin (NAMed) im DIN Deutschen
7、Institut fr Normung e.V.,10772 Berlin (Hausanschrift: Burggrafenstr. 6, 10787 Berlin). Diese Technische Spezifikation CEN/TS 14822 legt generelle Anforderungen fr allgemein verwendbare Informationskomponenten, die in Normen zum Datenaustausch eingesetzt werden, unter gesundheitsspezifischen Aspekten
8、 fest. Computersysteme sollten ihre Informationen effektiv austauschen knnen. Dafr sind Festlegungen zwischen den kommunizierenden Parteien, insbesondere fr deren Computersysteme, bezglich der Darstellung der Informationen festzulegen. Dieser Austausch von Informationen erfolgt dabei in verschiedene
9、n Ebenen, meistens erfolgt dies auf einer Datendarstellungs- oder syntaktischen Ebene, wie sie in der CEN/TS 14796 beschrieben wird, aber auch auf einer Makro- oder semantischen Ebene, wo Datengruppen verwendet werden, um den Zusammenhang oder eine Gruppe von Zusammenhngen fr die Daten darzustellen.
10、 Diese Technische Spezifikation beschrnkt sich auf die Beschreibung von Komponenten, die zustndig fr den Datentransfer sind, insbesondere auf Nachrichtendateikpfe. Vornorm TECHNICAL SPECIFICATION SPCIFICATION TECHNIQUE TECHNISCHE SPEZIFIKATION CEN/TS 14822-4 June 2005 ICS 35.240.80 English version H
11、ealth informatics General purpose information components Part 4: Message headers Informatique de sant Unit dinformation dans les messages Partie 4: En-ttes de message Informationskomponenten Teil 4: NachrichtendateikpfeThis Technical Specification (CEN/TS) was approved by CEN on 26 March 2005 for pr
12、ovisional application. The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard. CEN members are required to anno
13、unce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS) until the final decision about the possible conversion of t
14、he CEN/TS into an EN is reached. CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slo
15、venia, Spain, Sweden, Switzerland and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG Management Centre: rue de Stassart, 36 B-1050 Brussels 2005 CEN All rights of exploitation in any form and by any means reserved worldwide for CE
16、N national Members. Ref. No. CEN/TS 14822-4:2005: EMedizinische Informatik Allgemein verwendbare CEN/TS 14822-4:2005 (E) 2 Contents Page Foreword3 1 Scope 5 2 Normative References.5 3 Terms and Definitions .5 4 Symbols and Abbreviations .6 5 Rules Governing the Use of General Purpose Information Com
17、ponents6 6 General Purpose Information Components 7 Annex A (informative) How to read the models . 16 Bibliography. 18 Vornorm CEN/TS 14822-4:2005 (E) 3 Foreword This document (CEN/TS 14822-4:2005) has been prepared by Technical Committee CEN/TC 251 Health Informatics, the secretariat of which is he
18、ld by NEN. This is part four of the multi part standard EN 14822: Health informatics - General purpose information components with the following parts: Part 1: Overview Part 2: Non-Clinical Part 3: Clinical Part 4: Message headers According to the CEN/CENELEC Internal Regulations, the national stand
19、ards organizations of the following countries are bound to announce this CEN Technical Specification: Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Por
20、tugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom. Vornorm CEN/TS 14822-4:2005 (E) 4 Introduction Many previous messaging and information structure standards for health have overlapping parts with a number of objects being defined in separate documents, sometimes with small va
21、riations making implementation of conformant applications more difficult. It therefore makes sense to define a set of general purpose components that can be used for definition of message structures for different purposes. This approach was suggested and approved as a strategy for CEN/TC 251 in the
22、Short Strategic Study on message standards alignment in 1999 examining a set of five European Standards for messages. This Technical Specification is aiming to provide such a set of components and has been developed jointly with a new European Standard for Service Request and Report messages that is
23、 using the components defined herein. Another important background to the development of this Technical Specification has been the wish for a harmonisation of information models for health developed in Europe and the USA expressed in the collaboration agreement entered March 2000 between CEN/TC 251
24、and HL7 (Health Level Seven, Ann Arbor. Michigan). The goal was set for a maximum degree of alignment while maintaining their independence and need to serve the business requirements of the respective markets but also to make the results available to ISO for possible international standardization. H
25、L7 have adapted a general strategy similar to CEN/TC 251 using information modelling expressed in UML (Unified Modelling Language) for their new standards and a lot of interaction and information sharing has occurred between CEN experts and HL7 in an open spirit of collaboration. This Technical Spec
26、ification includes a large number of objects which are technically identical to descriptions in draft documents of HL7, although partly described differently due to the fact that CEN is following the ISO rules for drafting and presentation of standards which HL7 is not. CEN wishes to express its gra
27、titude towards HL7 experts for generously sharing their models with the European expert team. This part 4 document is definition of a set of message header General Purpose Information Components. Vornorm CEN/TS 14822-4:2005 (E) 5 1 Scope It is now widely or even universally accepted that computer sy
28、stems that are used within healthcare to record information about the care given to patients need to share that information with other computer systems and their users. In order that computer systems may share information effectively there is a requirement that the communicating parties, and particu
29、larly their computer systems have a common understanding of how the information which they are sharing is represented. This sharing of representation needs to take place at a number of levels, most notably at the data representation or syntactic level which is the subject of CEN/TS 14796, but also a
30、t the macro or semantic level where groupings of data are used to provide a context or set of contexts for the data. This part 4 of the standard is limited to descriptions of components concerned with messaging, and in particular the message and batch headers. 2 Normative References Not applicable.
31、3 Terms and Definitions For the purposes of this Technical Specification, the following terms and definitions apply. 3.1 batch collection of messages 3.2 communicating party person, organisation or device which acts in the role of a sender or receiver of a communication 3.3 communication techniques
32、for the effective transmission of information, ideas, etc. Longmans 1995 3.4 healthcare agent healthcare person, healthcare organisation, healthcare device or that performs a role in a healthcare activity 3.5 message communication in writing, speech or by signals 3.6 organisation unique framework of
33、 authority within which a person or persons act, or are designated to act towards some purpose NOTE Groupings or subdivisions of an organisation may also be considered as organisations where there is need to identify them for information interchange. ISO/IEC 6523-1 Vornorm CEN/TS 14822-4:2005 (E) 6
34、4 Symbols and Abbreviations CS Coded Simple value CV Coded Value GPIC General Purpose Information Component II Instance Identifier INT Integer ST Character String TS Point in Time UML Unified Modelling Language 5 Rules Governing the Use of General Purpose Information Components 5.1 When using a GPIC
35、, a system which conforms to this Technical Specification shall implement all of the features (classes, associations, attributes) that are described within the GPIC core. In particular, A conformant system that utilises a GPIC shall be able to receive and process information present in all classes a
36、nd attributes, even where the attributes are specified as being optional. A conformant system that utilises a GPIC to send information shall not be obliged to populate optional attributes. 5.2 One of the GPICs described (MessageTransmission) in this part may be associated with another GPIC (RelatedM
37、essage) which in effect extends the functionality of the GPIC. This extension is informative in nature and shall not subject to conformance testing. Vornorm CEN/TS 14822-4:2005 (E) 6 General Purpose Information Components 6.1 Communicating Party 6.1.1 General Description GPIC Name CommunicatingParDe
38、scription Notes Examples UML RepresentationVornorm ty 4.001 Information about the devices and using these devices in the sending and/or receivinn shall have one de acting in r and at least one device/organisation which is acting as nication. generally concern ge. s that are acting cipient should be
39、nt of the message. Sending doctor, receiving laboratory CommunicationFunction type_cd: CS (sender, receiver) External Interface 1 1* classCode: CS Identifier(s) for the organisation that is acting as a communication sender or receiver name O ST Name of the organisation telecom O Telecom One or more
40、telecommunication numbers/addresses or the communicating organisation 6.2 Message Transmission 6.2.1 General Description GPIC Name MessageTransmission GPIC_ID = 4.002 Description The envelope into which a message is placed. Use This GPIC resides at the head of the message and therefore does not have
41、 a conventional GPIC interface requirement. However, the class ControlEvent is shown as the point at which the message content is to be attached. It is mandated that the ControlEvent class will interface to a class of general type ACT, i.e. the message content will always start with an ACT class or
42、one of its specialisations. Vornorm CEN/TS 14822-4:2005 (E) 10 Notes The ControlAct class is not described here except to the extent that it is necessary that the instance of MessageTransmission will normally be associated with a message payload and where there is a payload, this shall always start
43、with an Act class (ControlAct). Although the content of the ControlAct is not described here, the content should describe the act of message sending/receiving, i.e. provide information about the sender, receivers (as persons/organisations), the purpose of the message, date and time of its creation,
44、etc. MessageTransmission is not associated directly with a payload (ControlAct) only where a message is merely being referred to as in the RelatedMessage GPIC. UML Representation MessageTransmission creationTime: TS id: II interactionId: II versionCode: CS GPIC Core CommunicatingParty 1 2* 1 01 Cont
45、rolAct Message RelatedMessage 0* 1 Vornorm CEN/TS 14822-4:2005 (E) 11 6.2.2 MessageTranmission GPIC Core Description MessageTransmission Description Information about the message as a whole NOTE: This class concatenates the attributes of the HL7 RIM class Transmission and its specialisation class Me
46、ssage Related Classes Type of Relationship Cardinality CommunicationFunction (in CommunicatingParty GPIC) Association 2 to many ControlAct Association 0 or 1 Attributes O Type Description creationTime M TS The date/time that the sending system created the transmission. If the time zone is specified,
47、 it will be used throughout the transmission as the default time zone. id M II Unique identifier of the transmission. interactionId O II Unique identification of the message type. versionCode O CS Version of the messaging standard. This attribute is matched by the receiving system to its own version
48、 to be sure the message will be interpreted correctly. The set of allowable values (i.e. version identifiers) must be defined by the standards development body responsible for the definition and maintenance of the messaging standards. processingCode O CS Defines whether the message is part of a prod
49、uction, training, or debugging system VALUES: D = Debugging P = Production T = Training acceptAckCode O CS Identifies the conditions under which accept acknowledgements are required to be returned in response to this message. VALUES: AL Always ER Error/reject only NE Never SU Successful only Vornorm CEN/TS 14822-4:2005 (E) 12 responseCode O CS Specifies whether an application response is expected from the addressee of this interaction and what level of detail that response s
