 |
Whitepaper
|
 |
Neuerungen in der Version 2.6
Copyright Ringholm GmbH © 2006,2008. All Rights Reserved.
Unter http://www.ringholm.de/docs/00720_de.htm
können Sie die letzte Version dieses Dokumentes finden.
Author: Frank Oemig - Associated Sr.Consultant, Ringholm GmbH
Status dieses Dokumentes: Final, Version 1.0 (2007-01-16)
Senden Sie Fragen und Kommentare an
frank@oemig.de.
Zusammenfassung
Die Unterschiede zwischen den Versionen 2.5 und 2.6 sind relativ klein. Wichtig sind
- die separate Definition der Nachrichtenprifle, die jetzt in das Kaptiel 2B ausgelagert worden sind,
- Veränderungen in den Basisdatentypen TS und CE,
- optionales UAC-Segment in allen Nachrichten,
- neue Segmente und Felder für die Übermittlung von DRG-relevanten Informationen,
- "Mood-Code" in einigen Segmenten und
- die beiden neue Kapitel.
Außerdem fließen die Erfahrungen aus der Spezifikation der Version 3.0 in die 2.x-Versionen mit ein. Daher ist diese Version - mal wieder - die beste und vollständigste aus der 2.x-Serie.
1. Einleitung
Die nachfolgende Grafik zeigt sehr deutlich, daß die Anzahl an allem erhöht worden ist. Der Standard nimmt weiter an Umfang zu. Dies sieht man sehr deutlich an der Anzahl der Ereignisse (>300) und der Anzahl der Datenelemente (>2000):
Umgekehrt kann man aus der Grafik aber auch ablesen, dass insgesamt eine Harmonisierung durchgeführt wurde. Obwohl es mehr Ereignisse gibt, ist doch die Zahl der Nachrichten nicht so stark gestiegen. Die direkt über Events definierten Nachrichten haben stark abgenommen.
2. Datentypen
Die wohl markantesten Veränderungen im Kapitel der Datentypen ist die Abschaffung des Datentyps CE, der dann durch CNE und CWE ersetzt wird. Hier wird noch darüber diskutiert, welche Eigenschaften diese beiden Datentypen auszeichnen.
Darüber hinaus hat sich die Übertragung der Längeninformationen aus dem Kapitel 2A in die einzelnen Chapter durchgesetzt, d.h. die verschiedenen Anwendungsgebiete haben die vorgeschlagenen Längenangaben übernommen. Da es sich bei der Länge zwar offiziell um einen Maximalwert handelt, man aber individuell etwas anderes vereinbaren kann und in Deutschland dieser Wert nur als Empfehlung gehandhabt wird, dürfte sich diese Spalte in der Attributtabelle möglicherweise in der Version 2.7 erübrigen.
Unterstützt wird diese Vermutung durch bereits getroffene Entscheidungen, wo die Längenangabe ganz aus der Attributetabelle verschwinden wird.
Die Länge wird dann nur noch Bestandteil von Profilen sein und damit in der Verantwortung der
Hersteller liegen.
Abschaffung des CE-Datentyps
Wie schon einleitend erwähnt wird ab v2.6 der Datentyp CE nicht mehr verwendet. Die einzelnen HL7 technischen Kommittees hatten darüber zu befinden, ob die bisherigen Felder nun den Datentyp CNE oder CWE bekommen!
CNE vs. CWE?
In den Grundzügen, d.h. in den ersten 6 Komponenten, sind die drei Datentypen CE, CNE und CWE identisch. Erst danach unterscheiden sie sich:
CNE - Coded with no exceptions
Das wichtigste Unterscheidungsmerkmal auf Komponentenebene ist die Verpflichtung, die erste Komponente zu füllen:
| SEQ | LEN | DT | OPT | TBL# | COMPONENT NAME | SEC. REF. |
|---|---|---|---|---|---|---|
| 1 | 20 | ST | R | Identifier | 2.A.74 | |
| 2 | 199 | ST | O | Text | 2.A.74 | |
| 3 | 20 | ID | O | 0396 | Name of Coding System | 2.A.35 |
| 4 | 20 | ST | O | Alternate Identifier | 2.A.74 | |
| 5 | 199 | ST | O | Alternate Text | 2.A.74 | |
| 6 | 20 | ID | O | 0396 | Name of Alternate Coding System | 2.A.35 |
| 7 | 10 | ST | C | Coding System Version ID | 2.A.74 | |
| 8 | 10 | ST | O | Alternate Coding System Version ID | 2.A.74 | |
| 9 | 199 | ST | O | Original Text | 2.A.74 |
Darüber hinaus gibt es noch in der textuellen Erläuterung einen "kleinen" Unterschied:
Der Datentyp CNE darf nur genutzt werden, wenn es sich nicht um eine "user-defined Table" handelt. Dabei kommt es darauf an, dass die Tabelle im voraus bekannt ist und nicht erweitert werden kann/darf!
CWE - Coded with Exceptions
Hier nun die Spezifikation für CWE:
| SEQ | LEN | DT | OPT | TBL# | COMPONENT NAME | SEC. REF. |
|---|---|---|---|---|---|---|
| 1 | 20 | ST | O | Identifier | 2.A.74 | |
| 2 | 199 | ST | O | Text | 2.A.74 | |
| 3 | 20 | ID | O | 0396 | Name of Coding System | 2.A.35 |
| 4 | 20 | ST | O | Alternate Identifier | 2.A.74 | |
| 5 | 199 | ST | O | Alternate Text | 2.A.74 | |
| 6 | 20 | ID | O | 0396 | Name of Alternate Coding System | 2.A.35 |
| 7 | 10 | ST | C | Coding System Version ID | 2.A.74 | |
| 8 | 10 | ST | O | Alternate Coding System Version ID | 2.A.74 | |
| 9 | 199 | ST | O | Original Text | 2.A.74 |
Zeitpunkt: neuer Datentyp DTM als Ablösung von TS
In den bisherigen Versionen des Standards hat sich wohl niemand um die korrekte Handhabung des Datentyps "TS" bemüht. Genaugenommen besteht - oder bestand - dieser aus 2 Komponenten, wobei die 2. Komponente eine Angabe über die Genauigkeit machen sollte. Damit konnte die 1. Komponente mit "beliebig" vielen Ziffern gefüllt werden, denn in der zweiten Stand dann, wie viele davon gültig waren. Beispielsweise war der Zeitpunkt bis auf die Sekunde genau angegeben, jedoch sollte der Wert nur bis auf den Tag genau ausgewertet werden.
Diese Vorgabe wurde in der Praxis jedoch nicht umgesetzt. Vielmehr wissen die meisten Hersteller nicht einmal um die Existenz dieser zweiten Komponente. Für die Erweiterung des Standards hat diese "unnütze" Komponente jedoch Probleme bereitet, da auf der zweiten Datentyp-Ebene TS nicht genutzt werden konnte, da es keinen "Sub-Sub-Komponententrenner" gibt.
Der neue Datentype "DTM" ersetzt nun durchgängig den bisherigen "TS". Die Definition ist gleich geblieben, nur fehlt jetzt die 2. Komponente.
ED-Datentyp
Dieser Datentyp enthält folgende Komponenten:
| SEQ | LEN | DT | OPT | TBL# | COMPONENT NAME | SEC. REF. |
|---|---|---|---|---|---|---|
| 1 | 1027 | HD | O | Source Application | 2.A.33 | |
| 2 | 11 | ID | R | 0834 | Type of Data | 2.A.35 |
| 3 | 32 | ID | O | 0291 | Data Subtype | 2.A.35 |
| 4 | 6 | ID | R | 0299 | Encoding | 2.A.35 |
| 5 | 65536 | TX | R | Data | 2.A.78 |
Die zugeordneten Tabellen sind dabei neu organisiert worden:
Imported Table 0834 - MIME Types
Diese Tabelle ist neu und lehnt sich im Wesentlichen an die aus dem WWW bekannten Kürzel an:
| Value | Description | Comment |
|---|---|---|
| application | Application data | |
| audio | Audio data | |
| image | Image data | |
| model | Model data | RFC 2077 |
| text | Text data | |
| video | Video data | |
| multipart | MIME multipart package |
HL7 Table 0191 - Type of referenced data
Diese Tabelle wird nur noch wg. "Backward Compatibility" weitergeführt:
| Value | Description | Comment |
|---|---|---|
| AP | Other application data, typically uninterpreted binary data (HL7 V2.3 and later) | |
| AU | Audio data (HL7 V2.3 and later) | |
| FT | Formatted text (HL7 V2.2 only) | |
| IM | Image data (HL7 V2.3 and later) | |
| multipart | MIME multipart package | |
| NS | Non-scanned image (HL7 V2.2 only) | |
| SD | Scanned document (HL7 V2.2 only) | |
| SI | Scanned image (HL7 V2.2 only) | |
| TEXT | Machine readable text document (HL7 V2.3.1 and later) | |
| TX | Machine readable text document (HL7 V2.2 only) |
HL7 External Table 0291 - Subtype of referenced data
Diese Tabelle enthielt früher eine Reihe von Einträgen, von denen nur noch einer übrig geblieben ist:
| Value | Description | Comment |
|---|---|---|
| x-hl7-cda-level-one | HL7 Clinical Document Architecture Level One document | Retained for backwards compatibility only as of v2.6 and CDA R 2. Preferred value is text/xml. |
3. UAC-Segment
In der vorhergehenden Version des Standards wurde schon das SFT-Segment (Software) in alle Nachrichten eingebaut. In dieser Version ist es das UAC-Segment User Authentication Credential Segment), das Informationen über den Benutzer transportiert. In diesem Segment werden bspw. Kerberos-Tickets zur End-User-Identifikation in einem ED-Feld übertragen.
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 4 | CWE | R | 0615 | 02267 | User Authentication Credential Type Code | |
| 2 | 65536 | ED | R | 02268 | User Authentication Credential |
4. sich wiederholende Elemente
Bisher hat es bei sich wiederholenden Elementen (Segmente oder Felder) Schwierigkeiten gegeben, wie das in Update-Nachrichten zu interpretieren ist ? insbesondere wenn Teile einer Nachricht fehlen. Hier gibt es jetzt anhand von Beispielen Klarheit.
5. Conformance: Nachrichtenprofile
Die bisherigen Nachrichtenprofile werden um Informationen über das genutzte Vokabular erweitert. "Annotations" erlauben ebenfalls weitere Informationen in einem Nachrichtenprofil anzugeben. Außerdem können über einen Pattern-Matching-Mechanismus zu den einzelnen Elementen über die Object Constraint Language (OCL), reguläre Ausdrücke (RegEx) oder XPath-Angaben weitere Einschränkungen definiert werden. Über den gleichen Mechanismus können verschiedene Elemente auch in Beziehung zueinander gesetzt werden.
6. Patient Administration
PA hat ebenfalls in allen Nachrichten ein neues Segment eingeführt.
- ARV - Access Restriction
Damit kann sowohl auf Personen/Patienten- als auch auf Fallebene Zugangs-/Auskunftsbeschränkunge definiert werden.
7. DRG-relevante Informationen
Im Zuge der DRG-Abrechnung sollten für alle Informationen, die benötigt werden, Felder in den entsprechenden Segmenten bereitgestellt werden. Dazu sind die vorhandenen Segmente erweitert worden. Darüber hinaus ist noch ein Segment für die Stammdaten hinzugekommen.
In den hier genannten Segmenten sind nur die neuen Felder aufgelistet.
DRG-Segment
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 12 | 1103 | XPN | O | 02156 | Name of Coder | ||
| 13 | 705 | CWE | O | 0734 | 02157 | Grouper Status | |
| 14 | 20 | CWE | O | 0728 | 02158 | PCCL Value Code | |
| 15 | 5 | NM | O | 02159 | Effective Weight | ||
| 16 | 20 | MO | O | 02160 | Monetary Amount | ||
| 17 | 20 | IS | O | 0739 | 02161 | Status Patient | |
| 18 | 100 | ST | O | 02162 | Grouper Software Name and Version | ||
| 19 | 20 | IS | O | 0742 | 02163 | Status Financial Calculation | |
| 20 | 20 | MO | O | 02164 | Relative Discount/Surcharge | ||
| 21 | 20 | MO | O | 02165 | Basic Charge | ||
| 22 | 20 | MO | O | 02166 | Total Charge | ||
| 23 | 20 | MO | O | 02167 | Discount/Surcharge | ||
| 24 | 5 | NM | O | 02168 | Calculated Days | ||
| 25 | 20 | IS | O | 0749 | 02169 | Status Gender | |
| 26 | 20 | IS | O | 0749 | 02170 | Status Age | |
| 27 | 20 | IS | O | 0749 | 02171 | Status Length of Stay | |
| 28 | 20 | IS | O | 0749 | 02172 | Status Same Day Flag | |
| 29 | 20 | IS | O | 0749 | 02173 | Status Separation Mode | |
| 30 | 20 | IS | O | 0755 | 02174 | Status Weight at Birth | |
| 31 | 20 | IS | O | 0757 | 02175 | Status Respiration Minutes | |
| 32 | 20 | IS | O | 0759 | 02176 | Status Admission |
DG1-Segment
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 22 | 427 | EI | C | 02152 | Parent Diagnosis | ||
| 23 | 705 | CWE | O | 0728 | 02153 | DRG CCL Value Code | |
| 24 | 20 | IS | O | 0136 | 02154 | DRG Grouping Usage | |
| 25 | 20 | IS | O | 0731 | 02155 | DRG Diagnosis Determination Status |
Das erste neue Feld "Parent Diagnosis" dient der Verlinkung auf die "übergeordnete" Diagnose. Hiermit kann die Kreuz-/Stern-Notation realisiert werden.
Durch das neue REL-Segment ist dieses Feld aber schon überflüssig geworden.
Die restlichen Feldern dienen den ermittelten diagnosebezogenen DRG-Werten.
PR1-Segment
Status| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 21 | 20 | IS | O | 0761 | 02177 | DRG Procedure Determination Status | |
| 22 | 20 | IS | O | 0763 | 02178 | DRG Procedure Relevance |
Diese beiden neuen Felder dienen ausschließlich den prozedurbezogenen DRG-Informationen.
Master-Files
Die Stammdaten zu den DRGs werden mit dem neuen Ereignis M17 kommuniziert.
DMI - DRG Master File Information
Zu jedem DRG-Code gibt es ein paar Informationen, die statisch dazugehören und deshalb nicht in den normalen Nachrichten mit ausgetauscht werden. Diese Felder sind in diesem neuen Segment untergebracht.
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 250 | CNE | O | 0055 | 00382 | Diagnostic Related Group | |
| 2 | 1 | CNE | C | 0830 | 00381 | Major Diagnostic Category | |
| 3 | 7 | NR | C | 02231 | Lower and Upper Trim Points | ||
| 4 | 5 | NM | C | 02232 | Average Length of Stay | ||
| 5 | 7 | NM | C | 02233 | Relative Weight |
8. "Mood-Code"
Ein ganz neues Konstrukt in der v2-Familie ist der Mood-Code.
Denjenigen, die sich mit V3 auskennen, ist dieser Wert ein Begriff:
| INT | Intent |
| APT | Appointment |
| ARQ | Appointment Request |
| PRMS | Promise |
| PRP | Proposal |
| RQO | Request-Order |
| EVN | Event |
| EVN.CRT | Event Criterion |
| EXP | Expectation |
Dieses Feld wird in den Segmenten OBX, RXO, PRB, GOL, PTH und PRD eingeführt.
Auf den ersten Blick erscheint dieses Feld problematisch. Auf den zweiten Blick ist es das auch, da damit in bestehenden Nachrichten die Intention verändert werden kann, wenn man dieses Feld nicht korrekt auswertet. Deshalb darf dieses Feld nur in neuen Nachrichten verwendet werden.
Der Grund, um dieses Feld überhaupt aufzunehmen, liegt in der Problematik von Einweisungen (REF-Messages). Hier müssen Informationen in unterschiedlicher Laune ("Mood") kommuniziert werden. Darunter ist bspw. die Unterscheidung zwischen einem Benachrichtigung, Versprechen und Absicht zu verstehen.
9. Order Entry/Result Reporting
Im Laborbereich gibt es zwei neue Nachrichten:
- O37: OPL - Population/Location-Based Laboratory Order Message
- O38: OPR - Population/Location-Based Laboratory Order Acknowledgment Message
Die Struktur dieser Nachrichten zielt auf den Einsatz im Veterinärmedizinbereich ab. Nicht unerwähnt bleiben soll die Übersichtstabelle zu den Order Control Codes, damit man relativ leicht ersehen kann, welcher Code in welcher Nachricht genutzt werden darf.
9. Query
Eine kleinere aber längst überfällige Neuerung ist die Umbenennung der falsche Bezeichnung "Conformance Statement" in "Query Profile" um die richtige Intention wiederzugeben. Desweiteren werden eine Reihe von Nachrichten aus dem Standard entfernt:
- EQQ - embedded query language query
- RQQ - event replay query
- SPQ - stored procedure request
- VQQ - Virtual Table query
10. Observations
Auch im OBX-Segment wird ein Mood Code eingeführt. Allerdings darf dieses Feld aus Kompatibilitätsgründen in bereits genutzten Nachrichten nicht verwendet werden. In einigen Nachrichten wird das ROL-Segment eingeführt, um bei Befunden weitere Ärzte zuordnen zu können.
Des weiteren gibt es eine neue Nachricht:
- R25: OPU - Unsolicited Population/Location-Based Laboratory Observation Message
Diese Nachricht übermittelt die Befunde zu den neuen Aufträgen aus Kapitel 4.
11. Patient Care
Neben der Einführung des "Mood Codes" in den Segmenten GOL, PTH und PRB ist das neue Segment REL für "Relationship" erwähnenswert. Dieses Segment erlaubt die Verlinkung zwischen Entitäten innerhalb und außerhalb der Nachricht. Bei Entitäten ist hier an Diagnosen, Prozeduren, und Befunden gedacht. Außerdem kann hier die Art der Beziehung direkt mit angegeben werden. Beispielsweise ist eine Diagnose durch einen entsprechenden Befund begründet oder eine Komplikation steht in einem direkten kausalen Zusammenhang mit einer Maßnahme.
Allerdings wird dieses Segment noch in keiner Nachricht verwendet. Es wurde von den Australiern eingebracht, um für Überweisungsnachrichten die Menge an zu übermittelnden Daten zu reduzieren.
12. REL-Segment
Ein Segment ganz anderer Art ist das neue REL-Segment. Es wird zwar noch in keiner Nachricht genutzt, wird aber schon von den Australiern genutzt, um die für Einweisungen notwendigen Daten zu reduzieren. Dieses Segment dient dazu, beliebige Segmente und externe Objekte miteinander in Beziehung zu setzen. Die nachfolgende Segmentbeschreibung ist die Mischung aus der aktuellen Beschreibung gemäß Kapitel 12 (Patient Care) und der aufgrund negativer Kommentare notwendiger Ballot Reconciliation:
| SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | Kommentar |
|---|---|---|---|---|---|---|---|---|
| 1 | 4 | SI | C | 02240 | Set ID - REL | |||
| 2 | 705 | CWE | R | 02241 | Relationship Type | |||
| 3 | 60 | EI | R | 02242 | This Relationship Instance Identifier | |||
| 4 | 60 | EI | R | 02243 | Source Information Instance Identifier | neu: Source Object ID | ||
| 5 | 60 | EI | R | 02244 | Target Information Instance Identifier | neu: Target Object ID | SI/NM | R | ????? | neu: Source Set ID |
| SI/NM | R | ????? | neu: Target Set ID | |||||
| 6 | 60 | EI | O | 02245 | Asserting Entity Instance ID | |||
| 7 | 250 | XCN | O | 02246 | Asserting Person | |||
| 8 | 250 | XCN | O | 02247 | Asserting Organization | |||
| 9 | 250 | XAD | O | 02248 | Assertor Address | |||
| 10 | 250 | XTN | O | 02249 | Assertor Contact | |||
| 11 | 53 | DR | O | 02250 | Assertion Date Range | |||
| 12 | 1 | ID | O | 0136 | 02251 | Negation Indicator | ||
| 13 | 705 | CWE | O | 02252 | Certainty | |||
| 14 | 26 | NM | O | 02253 | Priority No ( relative ordering, workflow: plans etc) | |||
| 15 | 250 | NM | O | 02254 | Priority Sequence No ( rel preference for consideration) | |||
| 16 | 1 | ID | O | 0136 | 02255 | Separability Indicator |
Dieses Segment ist noch nicht endgültig. Vermutlich werden bereits festgelegte Attribute wieder aus dem Kapitel entfernt, um sich nicht zu weit festzulegen.
Offen ist auch noch, ob tatsächlich jeweils zwei Source/Target-Informationen angegeben werden müssen, oder ob man das nicht auf die Object-ID reduzieren kann. Es würde reichen, wenn man die externen Objekte eindeutig identifizert und dann nur noch diese externen IDs kommuniziert.
13. Claims and Reimbursement
Dieses neue Kapitel 16 basiert zum großen Teil auf NeCST, dem "National eClaims Standard" aus Kanada. Das Ziel ist Rechnungsinformationen zu übertragen. (In den USA steht für die Rechnungsinformationen X.12 zur Verfügung.) Damit dieses Kapitel auch in anderen Ländern anwendbar ist, wurden die Nachrichten und Segmente um Anforderungen aus Deutschland, der Schweiz und Argentinien erweitert. Damit ist es bspw. geeignet, um die für §301 SGB V notwendigen Daten zu transportieren.
Folgende Events werden neu definiert:
- E01: Submit Health Services Invoice
- E02: Cancel Health Services Invoice
- E03: Query Health Services Invoice Status
- E04: Re-Assess HealthCare Services Invoice
- E10: Edit/Adjudication Results
- E12: Request Additional Information
- E13: Additional Information Response
- E15: Payment/Remittance Advice
- E20: Submit Authorization Request
- E21: Cancel Authorization Request
- E22: Query Authorization Request
- E24: Authorization Response
- E45: Query Eligibility
Zur Realisierung der o.g. Nachrichten sind eine Reihe von neuen Segmenten notwendig:
- ADJ - Adjustment
- IPR - Invoice Processing Results
- IVC - Invoice Segment
- PMT - Payment Information
- PSS - Product/Service Section
- PSG - Product/Service Group
- PSL - Product/Service Line Item
- PYE - Payee Information
- RTI - Request for Information
14. Materials Management
Das neue Kapitel 17 beschäftigt sich mit der Handhabung von Material. Dazu gibt es zwei neue Domänen:
- Inventory Item Master Updates
- Sterilization and Decontamination
Inventory Item Master Updates
Neue Segmente für "Inventory Item Master":
- IIM - INVENTORY ITEM MASTER SEGMENT
- ITM - MATERIAL ITEM SEGMENT
- STZ - STERILIZATION PARAMETER SEGMENT
- VND - PURCHASING VENDOR SEGMENT
- PKG - PACKAGING SEGMENT
- PCE - PATIENT CHARGE COST CENTER EXCEPTION
- IVT - MATERIAL LOCATION SEGMENT
- ILT - MATERIAL LOT SEGMENT
Placer Request:
- SLR/SLS - REQUEST NEW STERILIZATION LOT (EVENT S28)
- SLR/SLS - REQUEST STERILIZATION LOT DELETION (EVENT S29)
- STI/STS - REQUEST ITEM (EVENT S30)
- SDR/SDS - REQUEST ANTI-MICROBIAL DEVICE DATA (EVENT S31)
- SMD/SMS - REQUEST ANTI-MICROBIAL DEVICE CYCLE DATA (EVENT S32)
Filler Request:
- STC/ACK - NOTIFICATION OF STERILIZATION CONFIGURATION (EVENT S33)
- SLN/ACK - NOTIFICATION OF NEW STERILIZATION LOT (EVENT S34)
- SLN/ACK - NOTIFICATION OF STERILIZATION LOT DELETION (EVENT S35)
- SDN/ACK - NOTIFICATION OF ANTI-MICROBIAL DEVICE DATA (EVENT S36)
- SCN/ACK - NOTIFICATION OF ANTI-MICROBIAL DEVICE CYCLE DATA (EVENT S37)
Sterilization and Decontamination
Neue Segmente für "Sterilization and Decontamination":
- SCP - STERILIZER CONFIGURATION SEGMENT
- SLT - STERILIZATION LOT SEGMENT
- SDD - STERILIZATION DEVICE DATA SEGMENT
- SCD - ANTI-MICROBIAL CYCLE DATA SEGMENT
15. Ausblick auf 2.7
Version 2.6 ist noch nicht endgültig verabschiedet, und trotzdem gibt es schon Vorschläge für 2.7. Abgesehen von der Tatsache, dass im Vorstand die Entscheidung für 2.7 bereits gefallen ist, kann als radikalste Änderung der Umgang mit den Längeninformationen erwartet werden.
16. Referenzen
[HL7] "HL7", 2007, http://www.hl7.org/, Version 2.6.
Über Ringholm GmbH
Die Ringholm GmbH basiert auf einem Zusammenschluß von europaweit anerkannten Experten auf dem Gebiet der Systemintegration von IT-Systemen im Gesundheitswesen. Ringholm bietet Schulungen, Projektbegleitung und Beratung im Bereich der Schnittstellenstandards und -technologien.Für mehr Informationen besuchen Sie http://www.ringholm.de oder rufen Sie uns an unter +49 700 RINGHOLM (+49 700 74644656).