HL7 v3 教育訓練計畫

HL7 v3HL7 v3 教育訓練計教育訓練計畫畫

HL7 Taiwan 協會秘書長范士展

[email protected] Taiwan Google 論壇 :

http://groups.google.com/group/hl7-taiwan

行政院衛生署行政院衛生署 9696 年度醫療資訊標準推動計畫年度醫療資訊標準推動計畫

版權所有：台灣健康資訊交換第七層協定協會

致謝 HL7 協會承行政院衛生署委託舉辦「 96 年度醫療資訊標準推動計畫」

感謝行政院衛生署補助教育訓練費用，本年度 HL7 協會舉辦之「 HL7 v3 教育訓練」課程完全免費。

議程表

Version 3 Tutorial Track Introduction to Version 3

Part-1: V3 Fundamentals Part-2: Version 3 Messaging

XML ITS and Data Types Message Wrappers and Transport Version 3 Documents

Clinical Document Architecture Introduction Clinical Document Architecture Advanced

Implementation Classes Part-1: Analysis and Specification Part-2: Implementation Mechanics

Tools Domain Specific Classes (eg., Clinical Genomics)

V3 Fundamentals

位元世界 1/2 一個位元 (bit) 可以代表一個

事實的兩個狀態。例如：電燈的“開”或“關” 性別的”男”或”女”（只有

這樣子嗎？）。兩個位元則可四種狀態

00 、 01 、 10 、 11 賦予意義：方向

00 代表東 01 代表西 10 代表南 11 代表北

三個位元…

2 Bit

01

01

00

01

23

11

21 20

3 Bit

01

01

00

01

23

11

0000

21 2022

01

45

00

01

67

11

1111

20

1 Bit

01

01

4 Bit

01

01

00

01

23

11

0000

01

45

00

01

67

11

1111

00000000

01

89

00

01

AB

11

0000

01

CD

00

01

EF

11

1111

11111111

21 202223

位元世界 2/2 n 個字元就具備有 2n個狀態。 n=8 時，稱之為位元組 (Byte) ，共 256 個狀態。分別給予指定的文數字或符號，稱之為ASCII 碼，美國訊息交換標準代碼。

Char Dec Oct Hex

! 33 0041 0x21

+ 43 0053 0x2b

0 48 0060 0x30

1 49 0061 0x31

A 65 0101 0x41

B 66 0102 0x42

a 97 0141 0x61

b 98 0142 0x62交換標準始焉！！交換標準始焉！！

資訊的層級事實 fact

所關心的某一事件。描述方向、性別。資料 data

此事件可以攜帶的資料。 00 代表往東、 01 代表往西， 10 代表往南， 11 代表往北。

資訊 information資料經過有目的處理。某人從原點 (0,0) 出發，收集 {00, 00, 10, 00}資料，得知離開原點至座標 (1,3)

知識 knowledge學習所得，前往該點有哪些路徑。 {00,10,00,00} 也可到座標 (1,3) 。資訊重現。

智慧 wisdom可以產生新的路徑資訊創新

但！資料但！資料 (( 訊訊 )) 交換在哪一層級交換在哪一層級但！資料但！資料 (( 訊訊 )) 交換在哪一層級交換在哪一層級從人的角度從人的角度從人的角度從人的角度從電腦的角度從電腦的角度從電腦的角度從電腦的角度

Data – medical datum

12080 120/80 120/80 mmHg(Systolic/Diastolic)

But, it’s hard to be recognized by computerBut, it’s hard to be recognized by computerSo, We need Context and Content

130/90Blood-pressure

資訊涵義句法方面 (Syntactic Aspect)

描述語法、儲存或訊息傳輸的文法或語法有關。語意方面 (Semantic Aspect)

資訊所呈現的意義實用方面 (Pragmatic Aspect)

意圖或將被達成的目標

台灣大勝日本台灣大勝日本 V.S. V.S. 台灣大敗日本台灣大敗日本

但！電腦傳遞的資訊是？但！電腦傳遞的資訊是？

資訊系統抽象過程

真實世界觀點電腦世界觀點

Logical Model

抽象觀念實做觀念 Physical Model

真實世界

電腦世界

需求問題

使用操作

需求書規格書程式碼

相同資料、不同思考

資料來源： Niilo Saranummi , PICNIC ARCHITECTURE

相同語意、不同見解

Requirement:Create a means to transport a singleindividual from home to place of work.

ManagementInterpretation

I TInterpretation

UserInterpretation

我們需要一個訊息參考架構




資料來源： Bentley Dittman ， SYSTEMS ANALYSIS AND DESIGN METHODS ， 5th Edition

What Is HL7?

HL7 組織起源於 1987 。

1997/6 成為 ANSI 授權之標準發展組織 (SDO, standards development organization)

Canada

NewZealand

Finland Germany

Netherlands

Japan

United States

United Kingdom

India

Taiwan

China

Czech Republic

And growing

Mexico

France

Argentina

Brazil

Australia

Denmark Greece

Ireland

Italy

SpainSweden

Switzerland

SouthKorea

Turkey

Uruguay

27 International Affiliates

HL7 訊息標準 (V2 and V3)

“醫療行為的電子資料交換標準” 讓醫療院所的不同系統及資料結構之間作溝通的方式

HL7 (Health Level Seven)

ISO-OSI Communication Architecture ModelISO-OSI Communication Architecture Model

1 Physical 1 Physical 2 Data Link 2 Data Link 3 Network 3 Network 4 Transport 4 Transport

CommunicationCommunicationCommunicationCommunication

5 Session 5 Session 6 Presentation 6 Presentation 7 Application 7 Application

FunctionFunctionFunctionFunction

ISO-OSI (Open System Interconnection)

為何使用新版本 ? V2 的問題

V2 主要的問題點 V3 已修正

•特別設計的方法論•太多的例外狀況•曖昧不明確 – 缺乏定義•人為保留作為與舊版本相容•不能明確指出或自動相容性測試•複雜，神秘的編碼規則•沒有標準的詞彙

An HL7 V2.3 Message

MSH|^~\&|LABGL1||DMCRES||199812300100||ORU^R01|LABGL1199510221838581|P|2.3|||NE|NE

PID|||6910828^Y^C8||NewmanÂlfredÊ||19720812|M||W|25 Centscheap Ave^^WhatmeworryÛT^85201^^P||(555)777-6666|(444)677-7777||M||773789090

OBR||110801^LABGL|387209373^DMCRES|18768-2^CELL COUNTS+DIFFERENTIAL TESTS (COMPOSITE)^LN|||199812292128||35^ML|||||||IN2973^Schadow^Gunther^^^^MDÛPIN||||||||||Ônce||||||CA20837^Spinosa^John^^^^MDÛPIN

OBX||NM|4544-3^HEMATOCRIT (AUTOMATED)^LN||45||39-49||||F|||199812292128||CA20837

OBX||NM|789-8ÊRYTHROCYTES COUNT (AUTOMATED)^LN||4.94|10*12/mm3|4.30-5.90||||F|||199812292128||CA20837

A sample results message

<Labrs3P00 T="Labrs3P00"> <Labrs3P00.PTP T="PTP"> <PTP.primrPrsnm T="PN"> <fmn T="ST">Sample</fmn> <gvn T="ST">George</gvn> <mdn T="ST">H</mdn> </PTP.primrPrsnm> </Labrs3P00.PTP> <Labrs3P00.SIOO_L T="SIOO_L"> <SIOO_L.item T="SIOO"> <SIOO.filrOrdId T="IID">LABGL110801</SIOO.filrOrdId> <SIOO.placrOrdId T="IID">DMCRES387209373</SIOO.placrOrdId> <SIOO.InsncOf T="MSRV"> <MSRV.unvSvcId T="CE">18768-2</MSRV.unvSvcId> <MSRV.svcDesc T="TX">CELL COUNTS+DIFFERENTIAL TESTS (COMPOSITE)</MSRV.svcDesc> </SIOO.InsncOf> <SIOO.SRVE_L T="SRVE_L"> <SRVE_L.item T="SRVE"> <SRVE.name T="CE">4544-3</SRVE.name> <SRVE.svcEvntDesc T="ST">HEMATOCRIT (AUTOMATED)</SRVE.svcEvntDesc> <SRVE.CLOB T="CLOB"> <CLOB.obsvnValu T="NM">45</CLOB.obsvnValu> <CLOB.refsRng T="ST">39-49</CLOB.refsRng> <CLOB.clnRlvnBgnDtm T="DTM">199812292128</CLOB.clnRlvnBgnDtm> </SRVE.CLOB> <SRVE.spcmRcvdDtm T="DTM">199812292315</SRVE.spcmRcvdDtm> </SRVE_L.item> </SIOO_L.item> </Labrs3P00.SIOO_L></Labrs3P00>

V3 XML Prototype - same data

V3 對 HL7 的好處降低可選項目：其結果為更明確的訊息對於應用系統邊界的隱含假設予以揭露讓定義更清楚、更完善、一致性宣告

HL7 V3.0Certified

面對複雜的健康照護環境：

V3 對 Providers 的好處

協助整合異質系統增加選擇創新方案中的最佳解決方案

支援整合現有系統提供可靠地驗證供應商一致性宣告

IBMIBM

V3 對 Vendors 的好處提供改良過協定來整合異質系統減少安裝的時間

降低 site-specific 之協調簡化介面程式

Vendor 可以將有發展特定產品，在區隔化市場中找到利基

Version 3 目標提供事件、資料元素與訊息架構增進清楚且精確的定義規範改進標準適應於改變試圖達成 “ plug and play” 目標

受認可之原則 Explicit Scope, Target Users Support for Legacy Systems Loosely Coupled Systems Internationalization Compatibility with Versions 2.X (limited) Management - ANSI and by-laws Uniform Trigger Event Model Information System Role

受認可之原則 (continued)

Conformance Claims The Version 3 Development Process Project Scope Version 3 Methodology - MDF Quality Assurance Processes Process Support Confidentiality of Patient Information Authenticated Authorization for Services Security, Privacy, and Integrity

方法論的使命在標準發展過程中採用現代化軟體工程技術，如物件導向分析設計、正規化建模技術

為訊息標準提供高品質、易讀性、與彈性

結合抽象概念與行為模型，使用角色定義在嚴格的工作產品中。

廣泛使用 UML 圖示來描述標準。

Version 3 新增項目 HL7 V3 adopts an Object Oriented (OO)

approach using Unified Modeling Language (UML) principles.

HL7 isn't just Level 7 any more!

HDF - HL7 Development Framework

September 2007 publication/ballot

http://www.hl7.org/v3ballot/html/index.htm

September 2007 publication/ballot

Types of Documents in the V3 Publication

各章節說明

An HL7 Version 2.X Spec

Common Specs

Common Specs

Chapter-Specific Specs






Chapters2 and 8

Chapters 3, 4, 6, ...

Trigger Event and Messages

Trigger Event and Messages

Segments and FieldsSegments and Fields

Contents of Existing HL7 V2.3

Trigger events Actions or occurrences

Messages Information content

Segments Repeating structures

Data elements Data representation

An HL7 Version 3.X Spec

Common Specs


Use Case Use Case ModelModel

Use Case Use Case ModelModel

Information Information ModelModel

Information Information ModelModel

Message ModelMessage ModelMessage ModelMessage Model

2-nd Order 1 choice of 0-n Drug 0-1 Nursing


Implementable Implementable Message Message

SpecificationSpecification

EDIFACT*EDIFACT*



EDIFACT*EDIFACT*

*Future Consideration



OLE/CORBAOLE/CORBA



OLE/CORBAOLE/CORBA



XML/ER7/…XML/ER7/…



XML/ER7/…XML/ER7/…

HL7 Reference

Model

HL7 Reference

Model

Interaction Interaction ModelModel

Interaction Interaction ModelModel

HL7 ModelingAbstractions:

ActivitiesActivities(Use Case Model)(Use Case Model)

Dispense Medications

Manage Care

Perform Lab Tests

Review Utilization

Objects Objects (Information (Information

Model)Model)

AccountAccount PatientPatient ProviderProvider EncounterEncounter OrderOrder

CommunicationCommunication (Interaction and (Interaction and Message Models)Message Models)

ADT PharmacyFinance

HALHAL

Version 2.x focused its energies at the communication level and covered the other abstractions only loosely in the specifications.

By demanding analysis of the requirements and information content, Version 3 assures consistency in and enhances the value of the resulting messages.

HL7 messageHL7 message

茶敘10:10 ～ 10:30

Defining V3 Messaging…

Version 3 Terminology

V3 DomainsWhere the functional content is… 相似需求功能之集合範例：

病患管理檢驗室

與 V2.x Chapter類似

Messaging Components

V3 使用 Messaging ComponentsMessaging Components 方式來表達每一個 DomainDomain 在訊息裡的行為及結構。

Messaging Components

Storyboard Application Role Trigger Event Interaction

Domain Message Information Model (DMIM) Refined Message Information Model (RMIM) Hierarchical Message Descriptor (HMD) Message Type (MT)

STATIC

DYNAMIC

DYNAMIC ：說明系統間互動 STATIC ：說明傳遞訊息的內容

V3 Message Development Methodology

A SystemA System

V3 Dynamic Model

B SystemB System

• Storyboard• Application Role• Trigger Event• Interaction

Storyboards: The V3 Drama

Bill BeakerEric Emergency

Karl Kid

Sara Specialize

Boris Bleeder

Carl Cutter

Emergency Encounter: Storyboard

急診 Check In Adam由救護車送抵好望醫院的急診室。他有呼吸道疼痛及心跳加速。值班醫師 Dr. Eric認為需要立即進行處理。急診室文書 Christopher在 Person Registry找出 Adam先生的病歷並完成急診 check-in

更新急診檢傷急診醫師檢查 Adam先生並請胸腔科的 Dr. Penny Puffer 醫師來會診。

Check Out Adam先生的病情穩定後便辦理出院。

Post Check Out 出院檢視病歷時發現有診斷碼的錯誤並更正病歷內容。

如何實作這個故事？

V3

V3

V3

從 Storyboard 開始

Trigger Events

如同 V2.x中， trigger events是解釋兩個系統間實際發生的溝通事件 .

範例 :急診檢傷開始

Emergency Encounter

Example Trigger Event

Dynamic Tie In: Trigger Events are often State Transition Based Trigger events are often based on state

transitions of core classes, especially the ACT class.Emergency Encounter Started (Admit)

Emergency Encounter Completed (Discharge)

NULL NULL ACTIVEACTIVE

ACTIVE ACTIVE COMPLETEDCOMPLETED

Emergency Encounter Trigger Events:

Emergency Encounter StartedNull -> Active

Emergency Encounter CompletedActive -> Completed

Emergency Encounter RevisedActive -> ActiveCompleted -> Completed

Emergency Encounter AbortedActive -> Aborted

Emergency Encounter NullifiedAny State -> Nullified

Application Roles

系統角色是描述傳送及或接收訊息的系統成員。

一個系統可扮演多個角色。系統角色 Stereotypes:

Placer FulfillerInformer Tracker

範例 : 檢驗醫令開立者 (placer)檢驗提供資料者 (Fulfiller)

Application Roles範例

OrderPlacer

Clinicians write orders for laboratory services

Laboratory determines if can perform the test and either rejects the order or promises to perform it.

Order Filler

V3 新加入項目： Interactions

唯一的定義，用以連接 A Trigger Event Receiver Responsibilities

- AND – Static Message Definition

列出參與的 app roles Sending Application Roles Receiving Application Roles

STATIC

DYNAMIC

Application Role 與 Interaction

Interactions:連結 Static與 Dynamic Messaging Components

DYNDYNSTATSTATSTATSTATSTATSTAT

DYNDYNDYNDYNDYNDYNDYNDYN

認清你的角色：可知道一切

Each Domain Provides an Interaction Index Each Domain Provides an Interaction Index By Application RoleBy Application Role

To Conformance

善用文件

Domain

Interaction

Sub domain(Topic)

Artifact Identification SystemHealth & Clinical Management Domains

Subsection: Operations (PO) Domain: Laboratory (POLB) Domain: Pharmacy (PORX)

Subsection: Records (RC) Domain: Medical Records (RCMR)

Administrative Management Domains

Subsection: Practice (PR) Domain: Patient Administration (PRPA) Domain: Scheduling (PRSC) Domain: Personnel Management (PRPM)

Subsection: Financial (FI) Domain: Claims & Reimbursement (FICR) Domain: Accounting & Billing (FIAB)

Specification Infrastructure

Subsection: Message Control (MC) Domain: Message Control Infrastructure (MCCI) Domain: Message Act Infrastructure (MCAI)

Subsection: Master File (MF) Domain: Master File Management Infrastructure (MFMI)

Subsection: Query (QU) Domain: Query Infrastructure (QUQI)

Subsection: Common Content (CO) Domain: Common Message Elements (COCT) Domain: Common Message Content (COMT)

Artifact Identification System

Artifact Code

Application Role AR

D-MIM (Domain Information Model) DM

HMD (Hierarchical Message Descriptor) HD

Interaction IN

Message Type MT

R-MIM (Refined Message Information Model) RM

Storyboard ST

Storyboard Narrative SN

Trigger Event TE

Artifact Identification System 範例 PRPA_AR00001UV00 Where: PR = Subsection: Practice PA = Domain: Patient Administration AR = Artifact: Application Role 00001 = 6 digit non-meaningful number assigned by

the TC to ensure uniqueness UV = Realm (the only current value is UV for unive

rsal) 00 = Current version number

SENDINGAPPLICATION

ROLE

V3 Message Definition

RECEIVINGAPPLICATION

ROLE

?TRIGGER EVENT

INTERACTIONINTERACTION

Where’s the Content?

STORYBOARDSTORYBOARD

Interaction:The “Static” Parts

V3 Static Model

?

• Domain Message Information Model (DMIM)• Refined Message Information Model (RMIM)• Hierarchical Message Descriptor (HMD)• Message Type (MT) Message Type (MT)

PatientPatient NamePatient Date of Birth

…

(XML/SCHEMA/ELEMENT/ATTRIBUTE)(XML/SCHEMA/ELEMENT/ATTRIBUTE)

Message Type (MT)

A Message Type specifies what data may appear as elements of the message and the order in which they will appear. Individual instances of a message are validated and decoded by referring to the definition of the message type.

All HL7 Version 3 Message Types are derived from a single data model - The Reference Information Model (RIM).

MT MT MT MT MT MT MT MT MT MT

RIM

DMIM DMIM

RMIM RMIM RMIM RMIM

HMD HMD HMD HMD HMD HMD

靜態模型結構

All Messages Based on the RIM(Reference Information Model) A harmonized information

model containing all the information specified in HL7 V3 messages.

In UML (Unified Modeling Language) format.

The “BIG” Picture

The “BIG” Picture

Information Modeling Language

Patient

name : PNDOB : Dateaddress : AD

Class defines things represents important concepts of

your domain concepts = things and ideas that

exist in your business important = subject of multiple

transactions like the definition of a data base

“record”

Name “compartment” of class

Attribute “compartment” of class• attributes are the data we record about

the things of interest• attributes are values that exist only with

with respect to the class.• attributes have a name and a data type• like the definition of a data field in a data

base record

Patient

name : PNDOB : Dateaddress : AD Patient

name = John DoeDOB = 10-Apr-1966address = Calgary

Patientname = Jane SmithDOB = 1-Oct-1956address = Toronto

Patientname = Bart SimpsonDOB = 5-Sep-1975address = Springfield

Information Modeling Language Class defines things Objects are instances

individuals of which classes are a definition

have values assigned to attributes have identity that’s invariant when

other values change like the “records” of a data base

Patient


Doctor

name : PNspecialty : CDphone : TEL

seeks care at

provides care for0..*

1..*

Information Modeling Language Class defines things Objects are instances Associations relate things

describe the way things relate to other things

“Association role name”

cardinality or “multiplicity”• specifies how many such association instances

each object instance can/must have

Patient


Doctor


seeks care at


1..*

Information Modeling Language Class defines things Objects are instances Associations relate things

describe the way things relate to other things

“Every Patient … seeks care at … 1 to many … Doctors”

“Reading” associations in plain English:

“Every Doctor … provides care for ... zero to many … Patients”


Patient


Doctor


seeks care at


1..*

Encounter

type : CVtime : IVLTSreason : CD

Class defines things Objects are instances Associations relate things Associative classes add properties

to relationships attributes about association more relationships


Patient


Doctor


1

1..*

Encounter


Class defines things Objects are instances Associations relate things Associative classes add properties

to relationships attributes about association more relationships

1

0..*


Patient

gender : CDdonor : BLV.I.P. : BL

Doctor

specialty : CDphone : TELprivileges: CV

Person


1

1..*

Encounter


1

0..*

Class defines things Objects are instances Associations relate things Associative classes Generalization classes

Generalization classes can simplify the model through reuse of common concepts express logical truths of the application domain work the other way as “specialization classes”


Patient

gender : CDdonor : BLV.I.P. : BL

Doctor

specialty : CDphone : TELprivileges: CV

Person


1

1..*

Encounter


1

0..*

0..10..1

follow-up

Class defines things Objects are instances Associations relate things Associative classes Generalization classes Reflexive associations

Reflexive associations structure instances of one classchain (predecessor-successor,) hierarchy (parent-child,) or network

第二節第一小時結束

Six Core Classes Act - Actions

Order, Observe, Encounter, Account

Entity - People, Places, Things Person, Location, Blood

Role Patient, Location of Care,

Specimen.

Act_Relationship Connects Acts.

Participation Connects Roles to Acts.

Role_Link Connects Roles.

Entity

Role

RIM Classes

Act

Act_Relationship

Entity Role

Participation

Role_Link

Non CoreNon CoreNon Core

particip

ates in

playshas

scopes has targethas

sourcehas

targethas

source

Associations between Roles and Entities: “Played and Scoped”

Doctor Patient

DowntownHospital

Uptown Hospital

Joe Smith

Plays Plays

Scoped

By

Scoped

By

Yellow colored on Models

Roles Specified by Class Code Examples:

LIC – Licensed Entity PROV – Healthcare Provider ASSIGNED – Assigned Entity NOK – Next of Kin GUAR – Guarantor PAT – Patient IDENT – Identified Entity SDLOC – Service Delivery Location SPEC - Specimen

Entity詳細說明 (與 Role 相似 )

Act

classCode: CS moodCode: CS id: SET<II> code: CD statusCode: SET <CS> etc.

V3: All About Acts

Orange colored on Models

Acts Have Class ENC - Encounter OBS - Observation (lab) SBADM - Substance Administration (pharmacy -admin) SPLY - Supply (pharmacy - dispense)

Act.classCode :: CS (1..1) Mandatory

Vocabulary domain: ActClass

Acts Have States

Act.statusCode :: SET<CS> (0..*)

Vocabulary domain: ActStatus

Acts Have Moods

ProposalPRP

Order/RequestRQO

PromisePRMS

EventEVN

你為什麼不整理你的房間 ?

快去整理房間 !

我會的 !

房間已整理完畢 .

Act.moodCode :: CS (1..1) Mandatory

Vocabulary domain: ActMood

Appointment Mood

AppointmentAPT

今天的房間整理安排下午三時

More Moods...

Definition - DEFfrom master file

Event Criterion - EVN.CRTprecondition, such as “if pain”

“整理房間” 指把床整理好 , 把衣服放在洗衣機 , 及把玩具收拾好 .

如果你想吃冰淇淋 , 那你趕快把房間整理好… .

V3 Lab Moods

Observation Placer Order V2 Placer Order

Observation Filler Order (Promise) V2 Filler Order

Observation Result (Event) V2 Observation

做 CBC 檢驗

我會幫你做你要求的 CBC 檢驗

這是你的 CBC 檢驗結果

CBC = Complete Blood Count

V3 Patient Encounter Moods

New Inpatient Encounter Appointment

Active Inpatient Encounter

新預約的住院病患

病患已經入院

Acts Can Have Codes

External coding systems: Lab Observation Act Codes

could be LOINC codes.

HL7 defined: Encounter Type are Act

Codes.

Encounter TypeInpatient

EmergencyAmbulatory

Home Health

<code code="1554-5" codeSystemName="LN" displayName="Serum Glucose“/>

Act.code :: CD (0..1)

Vocabulary domain: ActCode

Acts have Ids: Act.id Going Global in V3

II:•identifier that uniquely identifies a thing or object.•Examples include medical record number, order id, service catalog item id, etc.•Usually based on ISO Object Identifier (“OID”)

•OID Registry: http://www.hl7.org/oid/index.cfm

Not to be confused with code – which describes the KIND of Act.

id [1..1] (M) Act (II)

Properties of the II Data Type

<hl7:id root="2.16.840.1.113883.19.3.2409" extension="12345" >

補充說明

Associations between Acts and Roles: Relations and Participants

Acts are related to other acts via Act

RelationShips.

Entities in Roles participate in acts via Participations.

ActRelationship

把兩個 acts聯結在一起包含從簡單的 act群組到複雜的，如依時間計畫執行的 act 。

範例 : inFulfillmentOf [an order] componentOf [an encounter]

Salmon colored on Models

Types of Act Relationships

COMP - has component PERT - has pertinent info SEQL - is sequel OPTN - has option FLFS - fulfills RSON - has reason INST - instantiates PRCN - has precondition

OUTC - has outcome SUCC - succeeds RPLC - replaces OCCR - occurrence REFV - has reference values AUTH - authorized by COST - has cost GOAL - has goal PREV - has previous instance

ActRelationship.typeCode :: CS (1..1) Mandatory

Vocabulary domain: ActRelationshipType

Participation

Describes the involvement of an entity in an act. The entity is playing a role

(Joe Smith plays doctor). The role participates in an act. Examples:

Author [of an order]

(Ordering Doctor)

Admitter [of an encounter]

(Admitting Doctor)

Sky Blue Colored on Models

Types of Participations AUT - author ENT - data entry person CBC - call back contact PATSBJ - patient subject ADM - admitter PRF - performer ATND - attender CNS - consentor DIS - Discharger

SPC - specimen LOC - location ELOC - entry location DST - destination DEV - device TPA - therapeutic agent CSM - consumable RESPROV - responsible

providerParticipation.typeCode :: CS (1..1) Mandatory Vocabulary domain: ParticipationType

Adam’s Emergency:

Adam Everyman在 2006/5/2早上 10 點，經由救護車送達 Good Health Hospital 的急診處。 Everyman先生呼吸道疼痛及心跳加速的症狀。值班醫師 Eric Emergency ，認為他需要被緊急處理，並且要求胸腔科的 Dr. Penny Puffer 醫師前來會診。Adam 已經完成掛號。

Quiz: Adam’s Emergency Identify the main Act (focal Act):

Act.classCode = Act.Code = Act.Status = Act.Mood = Act.effectiveTime =

What Role does Adam play? Role.classCode =

Penny and Eric both play the doctor Role. How do these doctors Participate in Adam’s Emergency Encounter? Eric’s Participation.Type = Penny’s Participation.Type =

Adam arrived at the hospital via ambulance. His transportation is modeled as an Act. What is the ActRelationShip between Transportation and his Encounter? ActRelationship.Type =

Quiz: Adam’s Emergency 定義主要的 Act (focal Act):

Act.ClassCode = “ENC” Act.code =“EMER” Act.Status =“active” Act.moodCode =“EVN” Act.effectiveTime = “200605021000”

Adam 扮演甚麼角色 ? Role.classCode =“ASSIGNED”

Penny 與 Eric 都是扮演醫師角色。他們是如何參與 Adam’s Emergency Encounter? Eric’s Participation.typeCode =“ATND” Penny’s Participation.typeCode =“CON”

Adam arrived at the hospital via ambulance. His transportation is modeled as an Act. What is the ActRelationShip between Transportation and his Encounter? ActRelationship.typeCode =“ARR”

Attributes have Data Types and sometimes Vocabulary Domains

• ANY

• BL

• BN

• ED

• ST

• CD

• CS

• CO

• CE

• SC

• II

• TEL

• AD

• EN

• TN

• PN

• BAG

• IVL

• HIST

• UVP

• PIVL

• EIVL

• GTS

• PPD

180+ V3 Vocabulary Domains

AcknowledgementCondition..

WorkPlaceAddressUse

33 V3 Data Types

• ON

• INT

• REAL

• RTO

• PQ

• MO

• TS

• SET

• LIST

Many Attributesalso have Vocabulary Domains

180+ V3 Vocabulary Domains

AcknowledgementCondition..

WorkPlaceAddressUse

Coding Strength:

(for attributes with Vocabularies)

CNE = Coded No Exceptions

CWE = Coded With Exceptions


Vocabulary domain: ActClass (CNE)

bind HL7 attributes to value sets from external or internal terminologies8

Attributes can be MandatoryAttributes have Cardinality

Mandatory Flag: If an attribute is

Mandatory, it must be valued

or your message is not

valid V3.

Cardinality: How many?

(0..1)(1..1)(1..3)(1..*)


Vocabulary domain: ActClass (CNE)

The RIM is too general to specify the requirements of a specific V3 object

Using V3 methodology, refinements of the RIM are

created for specific functional contexts.

More specific information models are derived from the RIM.

The The “Constraint “Constraint

Cycle”Cycle”

Domain Message Information Model (DMIM)是由 RIM延伸出來的。所有都是針對特有 domain 建構而成 ( 例如 “ Patient Administration”) 。

會有多個“ entry points” 。屬性是有限制的。

Refined Message Information Model (RMIM) 資訊模型顯示在特定訊息或訊息集合中所有資料。

衍生自 DMIM ，是 DMIM 之子集合。屬性會進一步限制。只會有一個“ Entry Point”連接到特定焦點或主題類別。

Patient Administration DMIM

Active Emergency Encounter RMIM

New PersonRMIM

Hence, the Refined Message Information Model (RMIM) The RMIM is an Information model that shows all the

data for a particular message or message set. An RMIM can also be used to show the structure for a

clinical document. All RMIMs are derived from the RIM. Attributes constrained and refined based on functional

context. RMIMs have One Entry Point which points to a single

“focal” or “subject” class. While there is only one RIM, there are many many RM

IMs. Understanding RMIMs is KEY to understanding V3.

Example RMIM: Active Emergency Encounter

Entry PointFocal Class

How to Read RMIMs RMIMs are in an HL7 “proprietary” modeling format, not

UML. Classes cloned and renamed to improve readability Color matters ActRelationship and Participation represented as block arro

ws: makes models more compact. Source points to target

Roles Solid line = played Dashed line = scoped

Special Choice Box Representation Constraint boxes

For more information on RMIM modeling conventions, refer to the V3 Guide RMIM Messaging Component section (3.5)

Reading RMIMs:Classes are Cloned and Color Coded

Acts:EncounterEvent

A_EncounterValuablesLocation

A_ConsentA_ObservationDx

A_AccountAccomodationEvent

PatientTransportation

Entities:E_Organization

E_Place

Roles:R_NotificationParty

R_AssignedPerson

R_AssignedEntity

R_Patient

ServiceDeliveryLocation

R_AssignedOrganization

Participations:notificationContact

attenderconsultant

referrersubjectlocation

responsiblePartyadmitter

ActRelationships:componentOf

pertinentInformation2Authorization

pertinentInformation1ReferencesequelTo

arrivedBy

Vocabulary Domain

Reading RMIMs:Class Attribute Conventions

Bold means Mandatory

Data TypeCoding

Strength

Default Value

Cardinality

Asterisk * means required

After attribute After association

If you’ve got it, you gotta send it

• Its considered a conformance indicator. From a conformance perspective, an attribute can be required or optional or not permitted.

RMIMs can reference CMETS(Common Message Element Types)

一個 CMET 只是訊息的片段，並非一個完整的訊息

它包含了共同可重複使用的概念 CMETs 只是一些訊息的相關資料 – 並不是針對訊息本身例如 : 醫令訊息裡的 “ Encounter” 及 “ Pat

ient”

CMETs are defined by their own RMIMs. Example:R_Assigned_ Entity (contact)

CMETs can reference other CM

ETs

Choice Box:Can be a person,

device, or an organization.

Solid Line: Played By

Dotted Line:

Scoped By

Constraint

Refinement Review

Hierarchical Message Descriptors (HMD)and Message Types (MT) HMD’s are derived from

an RMIM. HMDs are subsets of the

RMIM. Further constrained. Similarly, Message Type

s are subsets of an HMD with further constraints.

MT MT MT MT MT MT MT MT MT MT

RIM

DMIM DMIM

RMIM RMIM RMIM RMIM

HMD HMD HMD HMD HMD HMD

Reading HMDs and MTs:The Tabular Views:

Results in a linear list of attributes and associations. Closest analogy to V2 message and segment layouts.

Do the “Walk”

HMD/MT: Attributes are defined in a similar manner as on RMIM

Cardinality: [1..1] Mandatory flag: (M) Class: Act Data Type: (CS) Coding Strength+Vocabulary Domain: {CNE:ACT} Default Value: Fixed “ACT”

Or Fixed Value if Mandatory and Vocabulary domain constrained to a single value

Other constraints and notes

classCode [1..1] (M) Act (CS) {CNE:ACT} Fixed: "ACT"

Field Definitions: Peering into the Foundation

Links to RIM for class and attribute definition.

Links to Data Types for type definition

Links to Vocabulary for valid values and value definition.

code [0..1] Act (CE) {CWE:ActCode}

HMD and MTs: Three different “views”

Table View Excel View Schema View

Example: Active Emergency Encounter HMD – Table View

Example: Active Emergency Encounter MT – Table View

午餐時間

12:00~13:30

Introduction to the Introduction to the Clinical Document ArchitectureClinical Document Architecture

CDA

Clinical Document Architecture ANSI/HL7 CDA R1.0-2000 ANSI/HL7 CDA R2.0-2005 Created & maintained by HL7 Structured Documents

Technical Committee (SDTC) A specification for document exchange using

XML, the HL7 Reference Information Model (RIM) Version 3 methodology and vocabulary (SNOMED, ICD, local,…)

CDA: A Document Exchange Specification

This is a CDA and this and this and this and this and this and this

CDA: A Document Exchange Specification CDA 可以是

Discharge SummaryCare Record SummaryProgress NoteH&PPublic health report

… 任何帶有簽章的內容

CDA: What is a document?

從 XML角度，任何一種都是“ document”

直覺的角度， documents是 :表現出歷史醫療記錄格式把分散的資料及片斷病歷敍述整合在一起

CDA 給一系列的 healthcare documents 一些規範

CDA Release 2, section 2.1: A clinical document ... 有以下的特色 :

Persistence 永久性 Stewardship管理性 Potential for authentication鑑別性 Context 關連性 Wholeness 完整性 Human readability閱讀性

因此 CDA documents 不是 : data 碎片除非已簽核出生至死亡的記錄已簽章文件的集合

The CDA document defined

Relationship to HL7 messages

CDA 補足 HL7 messaging 的規格 CDA 文件是已被定義且完整的資訊物件。他可以存在與訊息本體之外。

CDA 文件可用 MIME編碼放入 HL7 message 中

Messages

can be the same

differ

Messages

can be the same

differ

Documents

can be the same

differ

Documents

can be the same

differ

Content

Intent & use cases

CDA documents::HL7 messages

CDA documents::HL7 messages

Messages

temporary

system-to-system

... not messages

signed?legally accepted?

designed per use case

Messages

temporary

system-to-system

... not messages

signed?legally accepted?

designed per use case

Documents

persistent

human-to-human

care-givers are trained to create documents ...

have legal standing

defined by precedent

Documents

persistent

human-to-human

care-givers are trained to create documents ...

have legal standing

defined by precedent

Lifetime

Commu-nication

Relationto care-givers

Legalaspects

Source

HL7 V2.x

MSH|...EVN|...PID|...PV1|...TXA|...OBX|1|ED|...

|...

CDA documents are encapsulated as MIME packages within HL7 messages

Relationship to HL7 messages

HL7 V3

<Act.Code code="11488-4" codeSystem="2.16.840.1.113883.6.1" displayName="Consultation note"/>

<Act.text type="multipart/related"> MIME-Version: 1.0 Content-Type: multipart/related; boundary="HL7-CDA-boundary"; type="text/xml"; start="10.12.45567.43" Content-Transfer-Encoding: BASE64

General Relationship to Messaging

CDA can be the payload in any kind of message

And can be passed from one kind to another

V2

V3

X12

XDS

CDA = header + body

CDA Header Metadata required for document discovery, management,

retrieval

CDA Body Clinical report

Discharge Summary Care Record Summary Progress Note H&P Public health report

… any content that carries a signature

CDA Header

The header describes: The document itself (unique ID, document type

classification, version)Participants (providers, authors, patients…)Document relationships (to orders, other

documents…) Metadata sufficient for document management

XML Body: two types of markup

Human-readable “narrative block”, all that is required to reproduce the legal, clinical content

Optional machine-readable CDA Entries, which drive automated processes

Header Body

Readable: required Computable: optional

Sample CDA

CDA Header: Metadata

Identify Patient Provider Document type...

Sufficient for Medical records management Document management Registry/repositoryg Record locator service Store, query, retrieve

required

CDA Body: Human-readable report

Any type of clinical document H&P Consult Op note Discharge Summary...

Format: tif, PDF, HTML, XML: Paragraph List Table Caption Link Content Presentation

required

CDA Body: Machine Processible Model-based computable semantics:

Observation Procedure Organizer Supply Encounter Substance Administration Observation Media Region Of Interest Act

Optional

CDA: Incremental Computability

Standard HL7 metadata

Simple XML for point of care human readability

RIM semantics for reusable computability (“semantic interoperability”)

Investing in Information

CDA XML 可以簡單 CDA XML 可以複雜簡單的編碼相對的花費很少而複雜的編碼則須花費很少但你投入多少將得到多少 :

就像電池更替越詳細的編碼重複使用的機會就越高

CDA: How to Create

creating CDA documentseForms transcriptionknowledge basedynamic queryHL7 message conversion (V2 & V3)DICOM Structured Report transformEHR

eForms: Microsoft InfoPath

Adobe: Import CDA from Epic

Adobe: CDA Data from Epic

CDA from dictation

Dictaphone

CDA in desktop app

CDA from DICOM SR

GE RA600 created CDA as transformation from DICOM SR

The Simplest CDA

Enterminimal metadata

Point to document body

See HL7.org NLM Project

The CDA Spec Itself

Prose document (pdf or html) RMIM: Refined model (Visio or gif) HMD: Hierarchical Descriptor (table or spread

sheet) Data types: abstract and XML NOTE: W3C xsd schemas informative

CDA 文件

How the CDA is developed and maintained: just enough HL7 Development FrameworkReference Information Model

RMIM

Hierarchical Description

XML Schema

• linearization• additional constraints

• algorithm

• subset of RIM• tighten constraints

CDA Model

CDA Header CDA Body,Section, andNarrative Block

Ext'l Refs CDA Entries

The CDA Hierarchical Descriptor

R-MIM

CDA Header CDA Body, Section, and Narrative Block

CDA Entries Ext'l Refs

CDA Revisions & Addenda

CDA HeaderGood Health Clinic Consultation note Consultant: Robert Dolin, MDDate: April 7, 2000Patient: Henry Levin, the 7th MRN: 12345 Sex: MaleBirthdate: September 24, 1932

<?xml version="1.0"?><ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 CDA.ReleaseTwo.CommitteeBallot01.July.2003.xsd">

Header ElementsGood Health Clinic Consultation note Consultant: Robert Dolin, MDDate: April 7, 2000Patient:Henry Levin, the 7th MRN: 12345 Sex: MaleBirthdate: September 24, 1932

<id extension="c266" root="2.16.840.1.113883.3.933"/><code code="11488-4“codeSystem="2.16.840.1.113883.6.1“ displayName="Consultation note"/><title>Good Health Clinic Consultation Note</title><effectiveTime value="20000407"/><setId extension="BB35" root="2.16.840.1.113883.3.933"/><versionNumber value="2"/><relatedDocument typeCode="RPLC"> <parentDocument> <id extension="a123" root="2.16.840.1.113883.3.933"/> <setId extension="BB35"root="2.16.840.1.113883.3.933"/> <versionNumber value="1"/> </parentDocument> </relatedDocument>

<documnetationOf><inFulfillmentOf><authorization><componentOf>

R-MIM



Header ElementsGood Health Clinic Consultation note Consultant: Robert Dolin, MDDate: April 7, 2000Patient: Henry Levin, the 7th MRN: 12345 Sex: MaleBirthdate: September 24, 1932

<recordTarget><patientRole>

<id extension="12345" root="2.16.840.1.113883.3.933"/><patientPatient><name>

<given>Henry</given><family>Levin</family><suffix>the 7th</suffix></name>

<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>

<birthTime value="19320924"/></patientPatient></patientRole>

</recordTarget>

R-MIM



CDA Body

History of Present IllnessHenry Levin, the 7th is a 67 year old male referred for further asthma management. Onset of asthma in his twenties teens. He was hospitalized twice last year, and already twice this year. He has not been able to be weaned off steroids for the past several months. Past Medical HistoryAsthmaHypertension (see HTN.cda for details) Osteoarthritis, right kneeMedicationsTheodur 200mg BIDAlbuterol inhaler 2puffs QID PRNPrednisone 20mg qdHCTZ 25mg qd



<component><StructuredBody>

<component>

<section><code code="10164-2" codeSystem="2.16.840.1.113883.6.1" codeSystemN

ame="LOINC"/><text>Henry Levin, the 7th is a 67 year old male referred for further asthma manage

ment. Onset of asthma in his <delete>twenties</delete><insert>teens</insert>. He was hospitalized twice last year, and already twice this year. He has not been able to be weaned off steroids for the past several months. </text>

<title>History of Present Illness</title></section>

</component>

<content> <link><renderMultiMedia> <paragraph> <list> <item> <table> <tr> <th> <td><caption>

CDA Section Narrative BlockPast Medical History•Asthma•Hypertension (see HTN.cda for details) •Osteoarthritis, right kneeMedications•Theodur 200mg BID•Albuterol inhaler 2puffs QID PRNPrednisone 20mg qdHCTZ 25mg qdAllergies & Adverse ReactionsPenicillin - HivesAspirin - WheezingCodeine – Itching and nausea

<component> <section> <code code="10153-2" codeSystem="2.16.840.1.113883.6.1“ codeSystemName="LOINC"/> <text> <list> <item><content ID="a1">Asthma</content></item> <item><content ID="a2">Hypertension (see HTN.cda for details)</content></item> <item><content ID="a3">Osteoarthritis, <content ID="a4">right knee</content></content></item> </list> </text> <title>Past Medical History</title> <component1>

<Observation classCode="COND"><code code="G-1001" codeSystem="2.16.840.1.113883.6.5" codeSystemName="SNOMED" disp

layName="Prior dx"/> <effectiveTime value="1950"/> <value xsi:type="CD" code="D2-00036"

CDA Entries

XML File

How the XSDs fit together Namespace declar

ations Header Entries Narrative Datatypes

POCD_MT000040.xsd

CDA.xsd

NarrativeBlock.xsd

datatypes.xsd

datatypes-base.xsd

voc.xsd

entries

narrative

header

namespaces

The CDA Header

Document identification and classification

Participants

Related documents/events

The CDA Body

XML or non-XML

Non-XML body

XML Body

Series of recursive sections

Sections establish context and include narrative and entries

identify

set context

Section Narrative

CDA & V3 Data Types

CDAData type

茶敘15:00~15:30

Tools Overview

15:30~17:00

V3 process is documented in the Message Development Framework (MDF)

Use Case Model

Information Model

Interaction Model



Message Specification

• Captures healthcare requirements

• Defines scope for TSC approval

• Specifies data and its semantics

• Specifies major state transitions

• Specifies vocabulary for domains

• Defines information flows

• Defines communication roles

• Forms basis for conformance claims

• Defines message contents

• Apply constraints to the

information model and vocabulary

Message Development Framework (MDF) Is a Methodology for building HL7 models Is a description for defining HL7 standard

messages Full instruction book for HL7 participants Basis for member training Five years in development Continues to evolve as we gain experience

Reference Model RepositoryReference Model RepositoryReference Model RepositoryReference Model Repository

RequirementsRequirementsAnalysisAnalysis

Use CaseUse CaseModelModel(UCM)(UCM)

RequirementsRequirementsAnalysisAnalysis

Use CaseUse CaseModelModel(UCM)(UCM)

DomainDomainAnalysisAnalysis

DomainDomainInformation Information

ModelModel(DIM)(DIM)

DomainDomainAnalysisAnalysis

DomainDomainInformation Information

ModelModel(DIM)(DIM)

AnalysisAnalysisAnalysisAnalysis DesignDesignDesignDesign

InteractionInteractionDesignDesign

InteractionInteractionModelModel(IM)(IM)

InteractionInteractionDesignDesign

InteractionInteractionModelModel(IM)(IM)

MessageMessageDesignDesign

HierarchicalHierarchicalMessageMessage

DescriptionsDescriptions(HMD)(HMD)

MessageMessageDesignDesign

HierarchicalHierarchicalMessageMessage

DescriptionsDescriptions(HMD)(HMD)

ApprovalApproval

BallotsBallots

ApprovalApproval

BallotsBallots

VotingVotingVotingVoting

RIMRIMRIMRIM

2-nd Order2-nd Order 1 choice of1 choice of 0-n Drug0-n Drug

0-1 Nursing0-1 Nursing

2-nd Order2-nd Order 1 choice of1 choice of 0-n Drug0-n Drug

0-1 Nursing0-1 Nursing

MDF Model Relationships

Models developed in Phases

Use Case ModelUse Case ModelUse Case ModelUse Case Model

Use Case Diagram

Spec

UCM Spec

Information ModelInformation ModelInformation ModelInformation Model

Spec

DIM Spec

State DiagramClass Diagram

Message DesignMessage DesignMessage DesignMessage Design



h//mt:50”d”………

h//mt:50”d”………

Identify Actors & Events

Develop ScopeCreate Use Cases

Model new concepts

Harmonize withRIM

Draw initial contents from RIM

Develop MessageInformation Model

Develop Message Object Diagram

Specify HMD

Define Trigger Events

Define Application Roles

DefineInteractions

Create Conformance Claims

Interaction ModelInteraction ModelInteraction ModelInteraction Model

Interaction Diagram

Spec

Inter Spec

V3 Message Development Methodology

Use Case Modeling

Produce a storyboard example by writing a simple example for your domain that illustrates where information is (or should be) transferred to accomplish a clinical scenario. This is to help you understand who is involved & how, what they need to know & when, and how they use computers to accomplish their tasks.

Generalize the storyboard example into a storyboard

Interaction Modeling Define application roles:

Look at the storyboard and decide where communication between systems will be needed. Consider the kind of system involved (HIS, lab, etc.) and include possible “decomposition” (e.g. if a hospital has a monolithic system, consider sub-functions like ADT and lab).

Use arrows to signify the information exchanges implied in the story board (e.g. A queries B for results, B responds.)

Review the communications and determine the primary content or subject of each (e.g. patient admission, x-ray results, orders, etc.)

Use the above to list application roles (e.g. order manager, admission tracker, etc.)

Interaction Modeling

Define interactionsLay out a rough collaboration diagram, in which

the application roles are boxes, and the information flows are directed arrows between them

Each arrow is an interaction. Label it with: An identifier The name of the trigger event The name or a summary of the message content to be

transferred

Information Modeling

Define classes, attributes, data types, and relationships

Define vocabulary domains, code systems, and value sets

Define states, trigger events, and transitions

Message Design

Define D-MIM, CMETs, and R-MIMs Define HMD and Message Types

Models are used to build the HMDUse Case Model

InteractionModel

HierarchicalMessage

Description

ReferenceInformation Model

MessageInformation

Model

CommonMessageElementTypes

DomainInformation

Model

Inpatient_encounter

actual_days_qtyestimated_days_qtyPatient_admission

admission_dttmadmission_reason_cdadmission_referral_cdadmission_source_cdadmission_type_cdpre_admit_test_indreadmission_ind

1

1is_preceded_by

1

preceded

1

Encounter_practitioner

participation_type_cdPerson_as_IHCP

phon : TIL

Person_name_for_IHCP

cd : CVpurpose_cd : CVtype_cd : CVnm : PN

1

1

has1

is_for

1

Patient_billing_account

id : TIIs tatus_cd : CVbilling_status_cd : CVpatient_financial_class_cd : CVprice_schedule_id : TII

Patient_encounter

id : TIIs tatus_cd : CVencounter_classification_cd : CVstart_dttmend_dttmexpected_insurance_plan_qty : NMfirst_similar_illness_dttm

1..*

1

is_associated_with

1..*

has_as_participant 1Individual_healthcare_practitioner

id : TII

0..*

1

is_participant_for 0..*

participates_as1

1

1

is_a_role_of

1

takes_on_role_of1

Patient

id : TIIs tatus_cd : CVnewborn_baby_indmultiple_birth_indorgan_donor_ind

0..1

1

belongs_to

0..1

has1

1

1

involves

1

is_involved_in

1

0..*

0..1

has_a_primary_provider0..*

is_the_primary_provider_for0..1Person_as_Patient

birth_dttm : TSbirthplace_addr : STdeceased_dttm : TSeducation_level_cd : CVgender_cd : CVmarital_s tatus_cd : CVrace_cd : CVreligious_affiliation_cd : CVphon : TIL

1..1

1..1

is_a_role_of

1..1

takes_on_role_of

1..1

Person_name_for_Patient

nm : PNeffective_dt : TScd : CVpurpose_cd : CVtermination_dt : TStype_cd : CV

1

1..*

has

1

is_for1..*

Exactly one occurrence

Domain Specification Database

10 Steps to V3 – Interactions from Storyboards1. Storyboard – Write a simple example for your domain that illustrates wh

ere information is (or should be) transferred to accomplish a clinical scenario. This is to help you understand who is involved & how, what they need to know & when, and how they use computers to accomplish their tasks.

2. Application roles –a. Look at the storyboard and decide where communication between systems

will be needed. Consider the kind of system involved (HIS, lab, etc.) and include possible “decomposition” (e.g. if a hospital has a monolithic system, consider sub-functions like ADT and lab.)

b. Use arrows to signify the information exchanges implied in the story board. (e.g. A queries B for results, B responds.)

c. Review the communications and determine the primary content or subject of each.(e.g. patient admission, x-ray results, orders, etc.)

d. Use the above to list application roles (e.g.order manager, admission tracker, etc.)

10 Steps to V3 – Interactions from Storyboards3. Interactions

a. Lay out a rough collaboration diagram, in which the application roles are boxes, and the information flows are directed arrows between them

b. Each arrow is an interaction. Label it with:i. An identifierii. The name of the trigger eventiii. The name or a summary of the message content to be transferred

4. Fill out the PubDB for the Trigger Events, Application Roles, Message Types and Interactions you have defined.

10 Steps to V3 – R-MIM design from Interactions5. Consider the message contents for the interactions you have just defined.

For each, summarize in list form, using common terms the information elements that need to be transferred. (e.g. Admission including patient demographics, MRN, Admitting MD; an order for a tele-health specialty consultation; query for lab and radiology results for last ten days; etc.)

6. Order and structure the lists from the previous step to indicate what is subordinate to what, how the information elements might be grouped, etc.

7. For the information groupings, identify which ones your team will need to design, and which you can develop by constraining or extending existing V3 designs.

10 Steps to V3 – R-MIM design from Interactions8. For the information groupings you will design, further classify them by th

eir likely RIM (R-MIM) representations: -Acts ActRelationships Participations -Roles Entities Other or undetermined

9. Use the Visio R-MIM notation (perhaps on flip charts) to diagram the R-MIM fragment for each of your groupings. Include the likely or critical attributes for each. And specify the type code for each class, and the mood code for each Act.

10. Move your sketch to the RMIM Designer in Visio.

Tools Suite RoseTree: The RoseTree is a Visual Basic (VB) application that functions

as an interface to the HL7 repository, provides a browser for the HL7 RIM and Vocabulary; builds R-MIMs and HMDs from Visio designs and manages the repository storage of these; and generates the needed XML extracts from the repository to allow further processing. It requires Microsoft's MSXML4 to perform XML extracts from the repository.

R-MIM Designer: The HL7 R-MIM design templates provide a suite of Visual Basic software that works in conjunction with the RoseTree software to provide an interactive design capability for HL7 R-MIMs. The tools draw their source from the RIM and assure that all elements are appropriately defined using the RIM as a base.

Tools Suite PubDb: The PubDb is a set of linked forms in Access supported by

additional VBA code. It serves as a vehicle to document the dynamic or interaction model of a technical committee's design, and provides a structured documentation environment that enforces the HL7 methodology. Data from the PubDb is published using XML files extracted with the PublishingWidget and RoseTree DLLs. These functions also permit desktop publishing of the content for review by editors. The database also work with XMLSpy to provide WYSISYG editing of the limited mark-up that is permitted in the PubDb.

Design Repository: The HL7 design repository performs the central function within the current HL7 tools suite of maintaining the "authentic" representation of all HL7 normative artifacts for Version 3. This is a database designed in Microsoft Access. Its tables are structured in a hierarchy that mirrors the structure of the artifacts that it holds, as defined in the meta-model for the HL7 methodology. The file is in a ZIP archive.

Tools Suite V3 Generator: The V3 Generator, formally known as Schema Generator,

is implemented using Ant and Saxon as XSLT processor. The V3 Generator accepts the XML expressions of an HMD (exported from the repository by RoseTree) and, through a series of transforms, generates HL7 artifacts including: Static schemas, Interaction schemas, HTML table views, CSV files for Excel views and MIF files for static models, data types, and vocabulary. The tools are in a ZIP file. Extraction of the ZIP file must preserve the directory structure of the archive.

CMETinfo.txt: CMETinfo.txt file is used by the R-MIM design tools (in Visio) to specify the CMETs that may be included in a design. This file should be downloaded and placed in your Visio "Solutions\HL7" directory if it is more recently released than the Visio R-MIM Designer tools

FormalNamingSource: The file "HL7FormalNamersSourceFile.xml" in this archive is used by the HL7 R-MIM Designer (in Visio). This file holds the source data for the algorithms that automatically name clones and associations in an R-MIM design.

Hardware Requirements

Computer:

PC with 1.2 gigahertz (GHz) or higher processor clock speed recommended; 1 GHz minimum required (single or dual processor system); Intel Pentium/Celeron family, or AMD K6/Athlon/Duron family, or compatible processor recommended

Operating Systems:

Windows XP (recommended) Windows 2000 Professional (recommended)Windows NT 4.0 Workstation (SP 6.0a or later)*Windows 98*

Disk Space:

1.5 gigabytes (GB) of free hard disk space

Memory:128 megabytes (MB) of RAM or higher recommended (64 MB minimum supported; may limit performance and some features)

Monitor:Super VGA (800 x 600) or higher resolution with 256 colors; 16 or 32-bit color recommended

Compact Disc

CD-ROM or DVD drive

Internet:Any internet connection; broadband (cable or DSL) connection (recommended for downloading the HL7 software distribution)

軟體需求說明 Altova XMLSpy: This is required for WYSIWYG editing from the PubDb, and is

very useful for reviewing and manipulating schemas, XML exports, etc. XMLSpy is the "tool of choice" for these functions. HL7 has XMLSpy licenses that it can distribute to committee members developing the standards. A full-function version of XML Spy can be downloaded for 30-day evaluation at http://www.altova.com/download.html

MSXML 4: This XML support software from Microsoft is required for both the R-MIM Designer in Visio and RoseTree. It is installed as part of the RoseTree installation.

Saxon: Saxon is an XSLT processor that is required by the HL7 V3 Generator to convert XML output of the HMD designs (from RoseTree) into XSD files. A Saxon JAR file is installed as part of the V3 Generator package. It is the XSLT processor-of-choice for both HL7 publications, and for the V3 Generator.

Java Runtime Environment (download): The Saxon processor requires a Java runtime environment (JRE) version 1.4.2 from Sun Microsystems, which is distributed free of charge.

軟體需求說明 Windows Installer (download): The Windows Installer is a standard comp

onent of Windows 2000 and Windows XP. It installs applications distributed in an "msi" file format. Most users of earlier Windows releases have this installer on their machines from previous installations. If, when you try to install RoseTree, you find that you do not have it on your machine, you can download it from the above hyperlink or you can go to the MS site and search for "Windows installer".

Microsoft Office: The Microsoft Office suite, particularly Excel and Access, support various expressions of the HTML and HL7 artifacts. Excel is useful and is required to provide a tabular (grid) view of the HL7 HMD definitions. Access is also useful and is required to run the PubDb.

Microsoft Visio: Microsoft Visio, either version 2000 or 2002, is the foundation for the HL7 R-MIM designer. The current R-MIM Designer tool does not run on Visio 2003. HL7 cannot provide license for Visio.

軟體安裝注意事項 RoseTree must be installed before the R-MIM

Designer (in Visio). It also installs MSXML4, which is used by the R-MIM Designer and Visio.

Design Repository should be installed before the R-MIM Designer (in Visio).

Altova XMLSpy should be installed before the PubDb

Tools/data architecture (2005)

DEMO

Methodology Steps

HL7 tool suite could be divided into three categories: ScopeDynamic ModelStatic Model

Scope

本步驟要回答下列三個問題： What is communicated? What happens? Who is involved?

Storyboard Example: A clinician, using a local medical office support system, or

ders a lab test for one of her patients. The test will be performed on a specimen collected at her office. She will send the specimen by courier, and expects to receive a confirmation that the test will be performed, and a result of the test.

Dynamic Model

The dynamic model involves two steps: (a) Blocking out the Interactions

(b) Documenting the Interactions

Blocking out the Interactions The following critical questions need to be

answered when you decide to block out your interactions from the storyboard.

Who sends and receives? When to communicate? What is sent? Response obligations?

Blocking out the Interactions storyboard example

Initial order from MdOffice to LabMgmt; when the order is ready;

Content: patient, orderer, specimen, performer (lab), test; expect confirmation

Confirmation from LabMgmt to MdOffice; upon receipt and acceptance;

Content: order reference; performer; expected completionResult from LabMgmt to MdOffice; when test done;

Content: order reference; patient reference; findings; specimen status

Documenting the Interactions

The documentation of the interactions involves:

A. Defining or finding application roles for sender and receiver

B. Specifying the “trigger event” that initiates communication

C. Characterizing the interaction (types)

D. Documenting the message type required.

Documenting the Interactions

storyboard exampleA. McDuffie -> 1) Lab Order Placer; 2) Lab Confirmation

Receiver; 3) Lab Observation Event Tracker; LabMgmt -> 1) Lab order fulfiller; 2) Lab Promise confirmer; 3) Lab Observation Event Informer

B. 1) Order activate; 2) Promise activate; 3) Event completeC. 1) Request for action; 2) Request response; 3) Event notif

icationD. 1) Lab observation order; 2) Lab observation promise; 3)

Lab observation event

Static Model

The static model involves three steps:(a) Defining Subject-specific Information Model,

(b) Defining Message Design in an HMD

(c) Documenting the Message Design

Defining Subject-specific Information Model you should:

Identify a domain and or R-MIM to use as starting point Establish the clones, their attributes, and associations Aggregate or collect from a Domain Message Information

Model (D-MIM) Reference “Common” Types, as required Document the R-MIM Save to repository

Defining Message Design in an HMD This methodology step involves:

Walking the graph to serialize the R-MIMDefining message types based on (within) the

HMDDefining R-MIM constraintsSaving to repositoryExpressing HMD as XML, and/or CSV files

Documenting the Message Design

The final step in the methodology process is to use your defined message design to:Publish designs in ExcelCreate schemasPublish in HTML

Design Walkthrough

What RIM Classes Do We Need? Act (order) – Order

Participation – Author Role - Physician

Entity - Dr. Smith in the MD office Participation – Performer

Role – Laboratory Entity - The lab that will perform the test

Participation – Subject Role – Specimen

Participation – Record target Role – Patient in whose record the result goes

Act relationship – Definition Act (definition) – Ordered Test

Design Diagram

We have two options to work on this design: (a) Using Starter Diagram (參考別人）

http://hcxw2k1.nist.gov:8080/hl7services/index.jsp

(b) Designing from Scratch. （自己慢慢畫）

Understanding Basic Shapes 1/8

EntryPoint

Act & Entity Class


Role Class


Relationship Classes


Recursive Relationships


Non-Core Classes

Non-Core Associations


Choice


CMETs

Constraint


Notes

Page boxes & Page references

Attribute Conventions

The problem

Storyboard: A clinician, using a local medical office support system, orders a lab test for one of her patients. The test will be performed on a specimen collected at her office. She will send the specimen by courier, and expects to receive a confirmation that the test will be performed, and a result of the test.

What do we need? Act (order) – Order

Participation – Author Role - Physician

Entity - Dr. Smith in the MD office Participation – Performer

Role – LaboratoryEntity - The lab that will perform the test

Participation – Subject Role – Specimen

Participation – Record target Role – Patient in whose record the result goes

Act relationship – Definition Act (definition) – Ordered Test

This order …

…was authored by …

…a physician role played by…

Suzy Smith.

… of this order.

… was the author …

… in her role as a physician …

Suzy Smith …

HL7 Graphic representation

Foundation of HL7 modeling is defined in a UML profile, but we use an alternate graphic representation that better represents our “messages”

Persistent elements are in “square boxes” All attributes shown All constraints shown on the diagram

Phrases are shown as “Arrows” linking elements All attributes shown All constraints shown on the diagram

An Act constrained:by classCode to be an observation,

by moodCode to be an order

An Act constrained:by classCode to be an observation,

by moodCode to be a definition.

Common (reusable) types represent roles of patient, specimen,

healthcare workers

Building messages – persistent elements

Building messages – contextual phrases

Building messages – relational phraseThe author of the order is an assigned

entity role (healthcare worker)

The subject of the observation is a specimen role

1

2

4

6

8

3

5

7

9

10

11

OrderOrder

PhysicianPhysician

PerformerPerformer LaboratoryLaboratory

SubjectSubjectSpecimenSpecimen

Record targetRecord target PatientPatient

DefinitionDefinition

Ordered TestOrdered Test

AuthorAuthor

Automated serializing of graphic designOrder

Definition

Performer

Author

Record target

Patient

Laboratory

Physician

Ordered test

Subject

Specimen


Definition

Performer

Author

Record target

Patient

Laboratory

Physician

Ordered test

Subject

Specimen


Definition

Performer

Author

Record target

Patient

Laboratory

Physician

Ordered test

Subject

Specimen

Our example schemaThe subject

of the order

is a specimen

課程全部結束