Transcript HL7 v3教育訓練計畫

行政院衛生署
96年度醫療資訊標準推動計畫
HL7 v3教育訓練計畫
版權所有：台灣健康資訊交換第七層協定協會
HL7 Taiwan 協會
秘書長 范士展
[email protected]
HL7 Taiwan Google論壇:
http://groups.google.com/group/hl7-taiwan
致謝
HL7協會承行政院衛生署委託舉辦「96年度
醫療資訊標準推動計畫」
 感謝行政院衛生署補助教育訓練費用，本
年度HL7協會舉辦之「HL7 v3教育訓練」課
程完全免費。

議程表
Version 3 Tutorial Track

Introduction to Version 3





XML ITS and Data Types
Message Wrappers and Transport
Version 3 Documents





Clinical Document Architecture Introduction
Clinical Document Architecture Advanced
Implementation Classes


Part-1: V3 Fundamentals
Part-2: Version 3 Messaging
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代表北
三個位元…
20
0
1
0
1
4 Bit
3 Bit
2 Bit
1 Bit
21
20
0
0
1
1
0
1
0
1
0
1
2
3
22
21
20
0
0
0
0
1
1
1
1
0
0
1
1
0
0
1
1
0
1
0
1
0
1
0
1
0
1
2
3
4
5
6
7
23
22
21
20
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1
0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
位元世界 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
120
80
120/80
130/90
120/80 mmHg Blood-pressure
(Systolic/Diastolic)
But, it’s hard to be recognized by computer
So, We need Context and Content
資訊涵義

句法方面 (Syntactic Aspect)
 描述語法、儲存或訊息傳輸的文法或語法有關。

語意方面 (Semantic Aspect)
 資訊所呈現的意義

實用方面 (Pragmatic Aspect)
 意圖或將被達成的目標
台灣大勝日本 V.S. 台灣大敗日本
但！電腦傳遞的資訊是？
資訊系統抽象過程
需求
問題
真實世界觀點
Logical Model
真實
世界
電腦
世界
需求書 規格書 程式碼
抽象觀念
實做觀念
使用
操作
電腦世界觀點
Physical Model
相同資料、不同思考
資料來源： Niilo Saranummi , PICNIC ARCHITECTURE
相同語意、不同見解
Requirement:
Create a means to transport a single
individual from home to place of work.
Management
Interpretation
IT
Interpretation
User
Interpretation
資料來源： Bentley Dittman， SYSTEMS ANALYSIS AND DESIGN METHODS， 5th Edition
What Is HL7?

HL7 組織起源於1987。

1997/6成為ANSI授權之標準發展組織(SDO,
standards development organization)
27 International Affiliates
Argentina
Sweden
Australia
Switzerland
Brazil
Spain
South
Korea
And growing
New
Zealand
Netherlands
Taiwan
Mexico
Canada
Turkey
Japan
United
Kingdom
China
Uruguay
Italy
United States
Czech Republic
Denmark
Finland
Ireland
France
Germany
Greece
India
HL7 訊息標準 (V2 and V3)


“醫療行為的電子資料交換標準”
讓醫療院所的不同系統及資料結構之間作溝通的
方式
HL7 (Health Level Seven)
Function
Communication
7
6
5
4
3
2
1
Application
Presentation
Session
Transport
Network
Data Link
Physical
ISO-OSI Communication Architecture Model
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^Alfred^E||19720812|M||W|25 Centscheap Ave^^
Whatmeworry^UT^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^UPIN
||||||||||^Once||||||CA20837^Spinosa^John^^^^MD^UPIN
OBX||NM|4544-3^HEMATOCRIT (AUTOMATED)^LN||45||39-49
||||F|||199812292128||CA20837
OBX||NM|789-8^ERYTHROCYTES COUNT (AUTOMATED)^LN||4.94|10*12/mm3
|4.30-5.90||||F|||199812292128||CA20837
A sample results message
V3 XML Prototype - same data
<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 對HL7的好處

降低可選項目：其結果為更明確的訊息

對於應用系統邊界的隱含假設予以揭露

讓定義更清楚、更完善、一致性宣告
HL7 V3.0
Certified
V3 對 Providers的好處
面對複雜的健康照護環境：
 協助整合異質系統
 增加選擇創新方案中的最佳
解決方案
 支援整合現有系統
 提供可靠地驗證供應商一致
性宣告
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
Chapters
2 and 8
Common
Specs
ChapterChapterChapterSpecific
Specific
Specific
Specs
Specs
Specs
Segments
and Fields
Chapters
3, 4, 6, ...
Trigger
Event and
Messages
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
HL7
Reference
Model
Common
Specs
ChapterSpecific
Specs
*Future
Consideration
Use Case
Model
Information
Model
Interaction
Model
Message Model
2-nd Order
1 choice of
0-n Drug
0-1 Nursing
Implementable
Message
Implementable
Specification
Implementable
Message
Message
Specification
XML/ER7/…
Specification
OLE/CORBA
EDIFACT*
HL7 Modeling
Abstractions:
Activities
(Use Case Model)
Objects
(Information
Model)
Perform Lab
Review
By demanding
Tests
Utilization
analysis
Version 2.x focused
its of the
and
energies at the requirements
communication
information
level and covered
the othercontent,
Version
3 in
assures
abstractions
only
loosely
the
Account
Order
Patient Provider Encounter
consistency
in
and
specifications.
enhances the value
of the resulting
messages.
Dispense
Medications
Communication
Manage
Care
HL7 message
HL7 message
(Interaction and
Message Models)
Finance
ADT
Pharmacy
茶敘
10:10～10:30
Defining V3 Messaging…
Version 3 Terminology
V3 Domains
Where the functional content is…
相似需求功能之集合
 範例：

 病患管理
 檢驗室

與 V2.x Chapter類似
Messaging Components
V3使用Messaging Components方式來表達每一個
Domain在訊息裡的行為及結構。
Messaging Components
DYNAMIC




Storyboard
Application Role
Trigger Event
Interaction




DYNAMIC：說明系統間互動
STATIC：說明傳遞訊息的內容
STATIC
Domain Message Information Model (DMIM)
Refined Message Information Model (RMIM)
Hierarchical Message Descriptor (HMD)
Message Type (MT)
V3 Message Development
Methodology
V3 Dynamic Model
•
•
•
•
Storyboard
Application Role
Trigger Event
Interaction
A System
B System
Storyboards: The V3 Drama
Karl Kid
Boris Bleeder
Eric Emergency
Bill Beaker
Sara Specialize
Carl Cutter
Emergency Encounter: Storyboard

急診 Check In


更新急診檢傷


急診醫師檢查Adam先生並請胸腔科的Dr. Penny Puffer醫師來會診。
Check Out


Adam由救護車送抵好望醫院的急診室。他有呼吸道疼痛 及心跳加
速。值班醫師 Dr. Eric認為需要立即進行處理。急診室文書
Christopher在Person Registry找出 Adam先生的病歷並完成急診
check-in
Adam先生的病情穩定後便辦理出院。
Post Check Out

出院檢視病歷時發現有診斷碼的錯誤並更正病歷內容。
如何實作這個故事？
從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)
NULL
 Emergency
ACTIVE
Encounter Completed (Discharge)
ACTIVE
COMPLETED
Emergency Encounter Trigger Events:
Emergency Encounter Started
Null -> Active
Emergency Encounter Completed
Active -> Completed
Emergency Encounter Revised
Active -> Active
Completed -> Completed
Emergency Encounter Aborted
Active -> Aborted
Emergency Encounter Nullified
Any State -> Nullified
Application Roles
系統角色是描述傳送及或接收訊息
的系統成員 。
 一個系統可扮演多個角色。
 系統角色 Stereotypes:

Placer
Informer

Fulfiller
Tracker
範例:
 檢驗醫令開立者(placer)
 檢驗提供資料者(Fulfiller)
Application Roles範例
Clinicians write orders for
laboratory services
Order
Placer
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
Application Role 與Interaction
Interactions:
連結Static與Dynamic Messaging Components
DYN
STAT
STAT
STAT
DYN
DYN
DYN
DYN
認清你的角色：可知道一切
Each Domain Provides an Interaction Index
By Application Role
善用文件
Domain
Sub domain
(Topic)
Interaction
Artifact Identification System
Health & 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
universal)
00 = Current version number
V3 Message Definition
STORYBOARD
INTERACTION
Where’s the Content?
SENDING
APPLICATION
ROLE
RECEIVING
APPLICATION
ROLE
Interaction:
The “Static” Parts
V3 Static Model
•
•
•
•
Domain Message Information Model (DMIM)
Refined Message Information Model (RMIM)
Hierarchical Message Descriptor (HMD)
Message Type (MT) 
(XML/SCHEMA/ELEMENT/ATTRIBUTE)
Patient
Patient Name
Patient Date of Birth
…
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.
RIM
DMIM
RMIM RMIM
HMD HMD HMD
DMIM
RMIM RMIM
HMD
All HL7 Version 3 Message Types are
derived from a single data model The Reference Information Model
(RIM).
HMD HMD
MT MT MT MT MT MT MT MT MT MT
靜態模型結構
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

Class defines things

Name “compartment” of class



Patient
name
: PN
DOB
: Date
address : AD
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”
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
Information Modeling Language


Class defines things
Objects are instances



Patient
name
: PN
DOB
: Date
address : AD

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
name = John Doe
Patient DOB = 10-Apr-1966
address
= Calgary
name = Jane
Smith
DOB = 1-Oct-1956
Patient
address = Toronto
name = Bart Simpson
DOB = 5-Sep-1975
address = Springfield
Information Modeling Language


“Association role name”

Class defines things
Objects are instances
Associations relate things

describe the way things relate to
other things
Patient
name
: PN
DOB
: Date
address : AD
0..*
provides care for
seeks care at
Doctor
name
: PN
1..* specialty : CD
phone
: TEL
cardinality or “multiplicity”
• specifies how many such association instances
each object instance can/must have
Information Modeling Language



Class defines things
Objects are instances
Associations relate things

describe the way things relate to other
things
“Reading” associations in plain English:
Patient
name
: PN
DOB
: Date
address : AD
0..*
seeks care at
provides care for
Doctor
name
: PN
1..* specialty : CD
phone
: TEL
“Every Patient … seeks care at … 1 to many … Doctors”
“Every Doctor … provides care for ... zero to many … Patients”
Information Modeling Language




Class defines things
Objects are instances
Associations relate things
Associative classes add properties
to relationships


attributes about association
more relationships
Patient
name
: PN
DOB
: Date
address : AD
0..*
provides care for
Doctor
name
: PN
1..* specialty : CD
phone
: TEL
seeks care at
Encounter
type
: CV
time
: IVLTS
reason : CD
Information Modeling Language




Class defines things
Objects are instances
Associations relate things
Associative classes add properties
to relationships


Patient
name
: PN
DOB
: Date
address : AD
0..*
1
attributes about association
more relationships
Encounter
type
: CV
time
: IVLTS
reason : CD
1
1..*
Doctor
name
: PN
specialty : CD
phone
: TEL
Information Modeling Language

Person

name
: PN
DOB
: Date
address : AD



Patient
gender : CD
donor : BL
V.I.P.
: BL

0..*
1
Class defines things
Objects are instances
Associations relate things
Associative classes
Generalization classes
Encounter
type
: CV
time
: IVLTS
reason : CD
1
1..*
Doctor
specialty : CD
phone
: TEL
privileges: CV
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”
Information Modeling Language


Person

name
: PN
DOB
: Date
address : AD



Patient
gender : CD
donor : BL
V.I.P.
: BL
0..*
1
Class defines things
Objects are instances
Associations relate things
Associative classes
Generalization classes
Reflexive associations
Encounter
type
: CV
time
: IVLTS
reason : CD
1
1..*
Doctor
specialty : CD
phone
: TEL
privileges: CV
0..1
follow-up

0..1
Reflexive associations structure instances of one class
chain
(predecessor-successor,) hierarchy (parent-child,) or network
第二節第一小時結束
Six Core Classes


Act - Actions
 Connects Acts.
 Order,
Observe, Encounter,
Account

Entity - People, Places,
Things
 Person,

Location, Blood
Act_Relationship

Participation
 Connects

Role_Link
 Connects
Role
 Patient, Location
Specimen.
Roles to Acts.
of Care,
Role
Entity
Roles.
RIM Classes
Non
Core
Non
NonCore
Core
Participation
has
plays
Entity
Role
Act
scopes
has
target
Role_Link
has
source
Act_Relationship
Associations between Roles and
Entities: “Played and Scoped”
Downtown
Hospital
Uptown
Hospital
Scope
d
By
Scope
d
By
Doctor
Joe Smith
Patient
Yellow colored on
Models
Roles Specified by Class Code

Examples:
– 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
 LIC
Entity詳細說明(與Role相似)
V3: All About Acts
Act
classCode: CS
moodCode: CS
id: SET<II>
code: CD
statusCode: SET <CS>
etc.
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

Proposal
你為什麼不整理你的房間?
 PRP

Order/Request
 RQO

Promise
快去整理房間!
我會的!
 PRMS

Event
 EVN
房間已整理完畢.
Act.moodCode :: CS (1..1) Mandatory
Vocabulary domain: ActMood
Appointment Mood

Appointment
 APT
今天的房間整
理安排下午三
時
More Moods...

Definition - DEF
 from

master file
Event Criterion - EVN.CRT
 precondition,
such as “if pain”
“整理房間” 指把床整理好, 把衣服放在洗衣機,
及把玩具收拾好.
如果你想吃冰淇淋, 那你趕快把房間整理好
….
V3 Lab Moods

Observation Placer Order
 V2


Placer Order
Observation Filler Order
(Promise)
 V2
做CBC檢驗
Filler Order
我會幫你做你要求
的CBC檢驗
Observation Result (Event)
 V2
Observation
這是你的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.
<code
code="1554-5"
codeSystemName="LN"
displayName="Serum Glucose“
/>
Encounter Type
Inpatient
Emergency
Ambulatory
Home Health
Act.code :: CD (0..1)
Vocabulary domain: ActCode
Acts have Ids: Act.id
Going Global in V3
id [1..1] (M) Act (II)
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.
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
ActRelationShips.
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
provider
Participation.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 扮演甚麼角色?


Penny 與Eric 都是扮演醫師角色。他們是如何參與
Adam’s Emergency Encounter?



Role.classCode =“ASSIGNED”
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
33 V3 Data
Types
AcknowledgementCondition
..
WorkPlaceAddressUse
•
•
•
•
•
•
•
•
ANY
BL
BN
ED
ST
CD
CS
CO
•
•
•
•
•
•
•
•
CE
SC
II
TEL
AD
EN
TN
PN
•
•
•
•
•
•
•
•
•
ON
INT
REAL
RTO
PQ
MO
TS
SET
LIST
•
•
•
•
•
•
•
•
BAG
IVL
HIST
UVP
PIVL
EIVL
GTS
PPD
180+
V3 Vocabulary Domains
Many Attributes
also have Vocabulary Domains
180+
V3 Vocabulary Domains
Coding Strength:
AcknowledgementCondition
(for attributes with Vocabularies)
..
WorkPlaceAddressUse
CNE = Coded No Exceptions
CWE = Coded With Exceptions
Act.classCode :: CS (1..1) Mandatory
Vocabulary domain: ActClass (CNE)
bind HL7 attributes to value sets from external or internal terminologies8
Attributes can be Mandatory
Attributes have Cardinality
Act.classCode :: CS (1..1) Mandatory
Vocabulary domain: ActClass (CNE)
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..*)
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
“Constraint
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 Person
RMIM
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
RMIMs.
Understanding RMIMs is KEY to understanding V3.
Example RMIM: Active
Emergency Encounter
Entry Point
Focal 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
arrows: makes models more compact.


Roles




Source points to target
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
Entities:
Acts:
EncounterEvent
A_Encounter
ValuablesLocation
A_Consent
A_ObservationDx
A_Account
AccomodationEvent
PatientTransportation
E_Organization
E_Place
Roles:
Participations:
notificationContact
attender
consultant
referrer
subject
location
responsibleParty
admitter
R_NotificationParty
R_AssignedPerson
ActRelationships:
R_AssignedEntity
componentOf
pertinentInformation2
Authorization
pertinentInformation1
Reference
sequelTo
arrivedBy
R_Patient
ServiceDeliveryLocation
R_AssignedOrganization
Reading RMIMs:
Class Attribute Conventions
Bold means
Mandatory
Vocabulary
Domain
Default
Value
Cardinality
Data Type
Coding
Strength
Asterisk * means required


After attribute
After association
• Its considered a conformance
indicator. From a conformance
perspective, an attribute can be
required or optional or not
permitted.
If you’ve got it, you
gotta send it
RMIMs can reference CMETS
(Common Message Element Types)
一個CMET只是訊息的片段，並非一個
完整的訊息
 它包含了共同可重複使用的概念
 CMETs只是一些訊息的相關資料 – 並不
是針對訊息本身

 例如:醫令訊息裡的
“Patient”
“Encounter” 及
CMETs can
reference other
CMETs
CMETs are defined
by their own RMIMs.
Dotted
Line:
Scoped By
Example:
R_Assigned_ Entity (contact)
Constraint
Solid Line: Played
By
Choice Box:
Can be a person,
device, or an
organization.
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
Types are subsets of an
RMIM
HMD with further
constraints.
RIM
DMIM DMIM
RMIM RMIM RMIM
HMD HMD HMD
HMD HMD HMD
MT MT MT MT MT MT MT MT MT MT
Reading HMDs and MTs:
The Tabular Views:
Do the
“Walk”


Results in a linear list of attributes and associations.
Closest analogy to V2 message and segment layouts.
HMD/MT: Attributes are defined in a
similar manner as on RMIM
classCode [1..1] (M) Act (CS) {CNE:ACT} Fixed: "ACT"






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
Field Definitions:
Peering into the Foundation
code [0..1]
Act (CE) {CWE:ActCode}
Links to Data
Links to RIM for class Types for type
and attribute
definition
definition.
Links to
Vocabulary for
valid values
and value
definition.
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
Clinical 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
Summary
 Care Record Summary
 Progress Note
 H&P
 Public health report

… 任何帶有簽章的內容
CDA: What is a document?
從XML角度，任何一種都是“document”
 直覺的角度，documents是:

 表現出歷史醫療記錄格式
 把分散的資料及片斷病歷敍述整合在一起

CDA給一系列的healthcare documents 一
些規範
The CDA document defined

CDA Release 2, section 2.1:
A clinical document ... 有以下的特色:
 Persistence 永久性
 Stewardship管理性
 Potential for authentication鑑別性
 Context關連性
 Wholeness完整性
 Human readability閱讀性

因此 CDA documents 不是:
碎片除非已簽核
 出生至死亡的記錄
 已簽章文件的集合
 data
Relationship to HL7 messages
CDA補足HL7 messaging的規格
 CDA文件是已被定義且完整的資訊物件。
他可以存在與訊息本體之外。
 CDA文件可用MIME編碼放入HL7 message
中

CDA documents::HL7 messages
Documents
Messages
Content
can be the same
can be the same
Intent &
use cases
differ
differ
CDA documents::HL7 messages
Documents
Messages
Lifetime
persistent
temporary
Communication
human-to-human
system-to-system
Relation
to caregivers
care-givers are
trained to create
documents ...
... not messages
Legal
aspects
have legal standing
signed?
legally accepted?
Source
defined by
precedent
designed per use
case
Relationship to HL7 messages
CDA documents are encapsulated as MIME
packages within HL7 messages
HL7 V3
HL7 V2.x
MSH|...
EVN|...
PID|...
PV1|...
TXA|...
OBX|1|ED|...
|...
<Act.Code code="11488-4"
codeSystem="2.16.840.1.113883.6.
1" displayName="Consultation
note"/>
<Act.text
type="multipart/related"> MIMEVersion: 1.0 Content-Type:
multipart/related;
boundary="HL7-CDA-boundary";
type="text/xml";
start="10.12.45567.43" ContentTransfer-Encoding: BASE64
General Relationship to Messaging

CDA can be the payload in any kind of
message
V2
X12
V3
XDS

And can be passed from one kind to another
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

Sample CDA


Header
Body
 Readable: required
 Computable: optional
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 documents
 eForms
 transcription
 knowledge
base
 dynamic query
 HL7 message conversion (V2 & V3)
 DICOM Structured Report transform
 EHR
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
Enter
minimal
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
spreadsheet)
 Data types: abstract and XML
 NOTE: W3C xsd schemas informative

CDA文件
How the CDA is developed and maintained:
just enough HL7 Development Framework
Reference Information Model
• subset of RIM
• tighten constraints
RMIM
• linearization
• additional constraints
XML Schema
• algorithm
Hierarchical Description
CDA Model
CDA Header
CDA Body,
Section, and
Narrative Block
CDA Entries
Ext'l
Refs
The CDA Hierarchical Descriptor
R-MIM
CDA Header
CDA Body,
Section, and
Narrative Block
CDA Entries
Ext'l
Refs
CDA Revisions & Addenda
CDA Header
Good Health Clinic Consultation note
Consultant:
Date:
Patient:
Birthdate:
Robert Dolin, MD
April 7, 2000
Henry Levin, the 7th
September 24, 1932
MRN: 12345 Sex: Male
<?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">
<!-********************************************************
CDA Header
********************************************************
-->
Header Elements
Good Health Clinic Consultation note
Consultant:
Robert Dolin, MD
Date:
April 7, 2000
Patient:Henry Levin, the 7th
MRN:
Birthdate:
September 24, 1932
12345
Sex: Male
<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"/>
<documnetationOf>
<setId extension="BB35" root="2.16.840.1.113883.3.933"/>
<versionNumber value="2"/>
<inFulfillmentOf>
<relatedDocument typeCode="RPLC">
<authorization>
<parentDocument>
<componentOf>
<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>
R-MIM
CDA Header
CDA Body,
Section, and
Narrative Block
CDA Entries
Ext'l
Refs
Header Elements
Good Health Clinic Consultation note
Consultant: Robert Dolin, MD
Date:
April 7, 2000
Patient:
Henry Levin, the 7th
MRN: 12345 Sex: Male
Birthdate:
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 Header
CDA Body,
Section, and
Narrative Block
CDA Entries
Ext'l
Refs
CDA Body
History of Present Illness
Henry 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 History
Asthma
<!-- (see HTN.cda for details)
Hypertension
********************************************************
Osteoarthritis,
right knee
CDA Body
Medications
********************************************************
Theodur
200mg BID
-->inhaler 2puffs QID PRN
Albuterol
<component>
Prednisone 20mg
qd
<StructuredBody>
HCTZ 25mg qd
<!--
R-MIM
CDA Header
CDA Body,
Section, and
Narrative Block
CDA Entries
Ext'l
Refs
CDA Section Narrative Block
History of Present Illness
Henry 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
<content>
weaned off steroids for the past several months.
<link>
<!--Past Medical History
********************************************************
<renderMultiMedia>
Asthma
History
of Present Illness section
<paragraph>
********************************************************
Hypertension (see HTN.cda for details)
-->
Osteoarthritis, right knee
<list> <item>
<component>
Medications
<section>
<table> <tr> <th> <td>
<code
code="10164-2"
codeSystem="2.16.840.1.113883.6.1"
Theodur 200mg BID
codeSystemName="LOINC"/>
<caption>
Albuterol inhaler
2puffs Levin,
QIDthe
PRN
<text>Henry
7th is a 67 year old male referred for further asthma
management.
Onset20mg
of asthma
Prednisone
qdin 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
HCTZ
25mg qd
months.
</text>
</section>
</component>
<title>History of Present Illness</title>
CDA Section Narrative Block
Past Medical History
•Asthma
•Hypertension (see HTN.cda for details)
•Osteoarthritis, right knee
Medications
•Theodur 200mg BID
<component>
<section>
•Albuterol inhaler 2puffs QID PRN
<code code="10153-2" codeSystem="2.16.840.1.113883.6.1“ codeSystemName="LOINC"/>
Prednisone 20mg qd
<text>
<list>
HCTZ 25mg qd
<item><content ID="a1">Asthma</content></item>
Allergies &ID="a2">Hypertension
Adverse Reactions
<item><content
(see HTN.cda for details)</content></item>
<item><content
ID="a3">Osteoarthritis, <content ID="a4">right knee</content></content></item>
Penicillin - Hives
</list>
Aspirin - Wheezing
</text>
Codeine
– Itching
and nausea
<title>Past
Medical
History</title>
CDA Entries
<component1>
<Observation classCode="COND">
<code code="G-1001" codeSystem="2.16.840.1.113883.6.5" codeSystemName="SNOMED"
displayName="Prior dx"/>
<effectiveTime value="1950"/>
<value xsi:type="CD" code="D2-00036"
XML File
How the XSDs fit together
datatypes.xsd
datatypesbase.xsd
header
voc.xsd
NarrativeBlock.xsd
narrative
entries
Namespace
declarations
 Header
 Entries
 Narrative
 Datatypes

namespaces
CDA.xsd
POCD_MT000040.xsd
The CDA Header
Document
identification
and
classification
Participants
Related
documents/
events
The CDA Body

XML or non-XML
Non-XML body
XML Body
identify
Sections establish
context and
include narrative
and entries
Series of recursive
sections
set context
Section Narrative
CDA & V3 Data Types
Data type
CDA
茶敘
15:00~15:30
Tools Overview
15:30~17:00
V3 process is documented in the Message
Development Framework (MDF)
Use Case Model
• Captures healthcare requirements
• Defines scope for TSC approval
• Specifies data and its semantics
Information Model
• Specifies major state transitions
• Specifies vocabulary for domains
Interaction Model
• Defines information flows
• Defines communication roles
• Forms basis for conformance claims
2-nd Order
1 choice of
0-n Drug
0-1 Nursing
• Defines message contents
Message Specification
• 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

MDF Model Relationships
Analysis
Requirements
Analysis
Domain
Analysis
Voting
Design
Interaction
Design
Message
Design
2-nd Order
1 choice of
0-n Drug
0-1 Nursing
Use Case
Model
(UCM)
RIM
Domain
Information
Model
(DIM)
Interaction
Model
(IM)
Hierarchical
Message
Descriptions
(HMD)
Reference Model Repository
Approval



Ballots
Models developed in Phases
Develop Scope
Create
Use Cases
Identify
Actors &
Events
Information Model
Use Case Model
Spec
Spec
DIM Spec
Class Diagram State Diagram
Define
Interactions
Create
Conformance
Claims
Model new
concepts
UCM Spec
Use Case Diagram
Harmonize with
RIM
Define Trigger
Events
Define Application
Roles
Draw initial
contents from
RIM
Interaction Model
Spec
Inter Spec
Interaction Diagram
Message Design
2-nd Order
1 choice of
0-n Drug
0-1 Nursing
h//mt:50”d”
…
…
…
Develop Message
Information Model
Develop
Message Object
Diagram
Specify HMD
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 interactions
 Lay
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 HMD
Reference
Information Model
Domain
Information
Model
Use Case Model
Interaction
Model
Person_name_for_IHCP
1
Person_as_IHCP
cd : CV
has
purpose_cd : CV
phon : TIL
1
type_cd : CV
nm : PN
is_for
takes_on_role_of
1
is_participant_for
0..*
Message
Information
Model
Encounter_practitioner
is_associated_with
participation_type_cd
1..*
Exactly one
occurrence
1 participates_as
has_as_participant
1
1 Individual_healthcare_practitioner
is_a_role_of id : TII
Patient_encounter
id : TII
s tatus_cd : CV
encounter_classification_cd : CV
Person_as_Patient
0..1 is_the_primary_provider_for
start_dttm
birth_dttm : TS
involves end_dttm
birthplace_addr : ST
0..* has_a_primary_provider
expected_insurance_plan_qty : NM
1 deceased_dttm : TS
1 first_similar_illness_dttm
Patient
education_level_cd : CV
1..1
id : TII
gender_cd : CV
takes_on_role_of
has
1
s tatus_cd : CV
marital_s tatus_cd : CV
1..1 newborn_baby_ind
race_cd : CV
is_involved_in
is_a_role_of multiple_birth_ind
religious_affiliation_cd : CV
Inpatient_encounter
organ_donor_ind
phon : TIL
1
actual_days_qty
1..*
has
Patient_admission
estimated_days_qty
is_for
admission_dttm
Person_name_for_Patient
Patient_billing_account
admission_reason_cd
1
nm : PN
admission_referral_cd
id : TII
is_preceded_by
effective_dt : TS
admission_source_cd 1
s tatus_cd : CV
0..1
cd : CV
admission_type_cd
billing_s tatus_cd : CV
preceded
purpose_cd : CV
pre_admit_test_ind
patient_financial_class_cd : CV
belongs_to
termination_dt : TS
readmission_ind
price_schedule_id : TII
type_cd : CV
Domain Specification Database
Hierarchical
Message
Description
Common
Message
Element
Types
10 Steps to V3 – Interactions from
Storyboards
1.
2.
Storyboard – Write 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.
Application roles –
a.
b.
c.
d.
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.)
10 Steps to V3 – Interactions from
Storyboards
3.
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 identifier
ii. The name of the trigger event
iii. 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
Interactions
5.
6.
7.
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.)
Order and structure the lists from the previous step to indicate what is
subordinate to what, how the information elements might be grouped, etc.
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
Interactions
8.
For the information groupings you will design, further classify them by
their likely RIM (R-MIM) representations:
-Acts
-Roles
9.
ActRelationships
Entities
Participations
Other or undetermined
Use the Visio R-MIM notation (perhaps on flip charts) to diagram the RMIM 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
Windows
Windows
Windows
XP (recommended)
2000 Professional (recommended)
NT 4.0 Workstation (SP 6.0a or later)*
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 32bit 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 RMIM 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 processorof-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
component 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:
 Scope
 Dynamic
Model
 Static Model
Scope

本步驟要回答下列三個問題：
 What
is communicated?
 What happens?
 Who is involved?

Storyboard Example:
 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.
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
completion
 Result

from LabMgmt to MdOffice; when test done;
Content: order reference; patient reference; findings;
specimen status
Documenting the Interactions

The documentation of the interactions
involves:
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.
A.
Documenting the Interactions

storyboard example
A.
B.
C.
D.
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
1) Order activate; 2) Promise activate; 3) Event complete
1) Request for action; 2) Request response; 3) Event
notification
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-MIM
 Defining message types based on (within) the
HMD
 Defining R-MIM constraints
 Saving to repository
 Expressing 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 Excel
 Create schemas
 Publish 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
Understanding Basic Shapes 2/8

Role Class
Understanding Basic Shapes 3/8

Relationship Classes
Understanding Basic Shapes 4/8

Recursive Relationships
Understanding Basic Shapes 5/8

Non-Core Classes

Non-Core Associations
Understanding Basic Shapes 6/8

Choice
Understanding Basic Shapes 7/8

CMETs

Constraint
Understanding Basic Shapes 8/8

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?

…This
of this
order.
order
…
…was
… wasauthored
the author
by…
…
Act (order) – Order
…
…ainphysician
her role as
role
a physician
played by…
…
 Participation – Author
Suzy
SuzySmith
Smith.…
 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
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
Building messages – persistent elements
An Act constrained:
by classCode to be an observation,
by moodCode to be an order
Common (reusable) types represent
roles of patient, specimen, healthcare
workers
An Act constrained:
by classCode to be an observation,
by moodCode to be a definition.
Building messages – contextual phrases
Building messages – relational phrase
The author of the order is an assigned
entity role (healthcare worker)
The subject of the observation
is a specimen role
Automated serializing of graphic design
Order
Author
1
Physician
Author
Performer
Laboratory
Order
Performer
10
3 Physician
Subject
5 Laboratory
7
Subject
Specimen
Specimen
Record target
Record target 9 Patient
Definition
11
Ordered Test
Patient
Definition
Ordered test
Automated serializing of graphic design
Order
Author
Physician
Performer
Laboratory
Subject
Specimen
Record target
Patient
Definition
Ordered test
Automated serializing of graphic design
Order
Author
Physician
Performer
Laboratory
Subject
Specimen
Record target
Patient
Definition
Ordered test
Our example schema
The subject
of the order
is a specimen
課程全部結束