hl7 v3 教育訓練計畫
Post on 19-Jan-2016
94 Views
Preview:
DESCRIPTION
TRANSCRIPT
HL7 v3HL7 v3 教育訓練計教育訓練計畫畫
HL7 Taiwan 協會秘書長 范士展
sjvann@gmail.comHL7 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^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
<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
Chapter-Specific Specs
Chapter-Specific Specs
Chapter-Specific Specs
Chapter-Specific 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
Chapter-Specific 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
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
Implementable Implementable Message Message
SpecificationSpecification
EDIFACT*EDIFACT*
Implementable Implementable Message Message
SpecificationSpecification
EDIFACT*EDIFACT*
*Future Consideration
Implementable Implementable Message Message
SpecificationSpecification
OLE/CORBAOLE/CORBA
Implementable Implementable Message Message
SpecificationSpecification
OLE/CORBAOLE/CORBA
Implementable Implementable Message Message
SpecificationSpecification
XML/ER7/…XML/ER7/…
Implementable Implementable Message Message
SpecificationSpecification
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
name : PNDOB : Dateaddress : AD
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
name : PNDOB : Dateaddress : AD
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
“Every Patient … seeks care at … 1 to many … Doctors”
“Reading” associations in plain English:
“Every Doctor … provides care for ... zero to many … Patients”
Information Modeling Language
Patient
name : PNDOB : Dateaddress : AD
Doctor
name : PNspecialty : CDphone : TEL
seeks care at
provides care for0..*
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
Information Modeling Language
Patient
name : PNDOB : Dateaddress : AD
Doctor
name : PNspecialty : CDphone : TEL
1
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
1
0..*
Information Modeling Language
Patient
gender : CDdonor : BLV.I.P. : BL
Doctor
specialty : CDphone : TELprivileges: CV
Person
name : PNDOB : Dateaddress : AD
1
1..*
Encounter
type : CVtime : IVLTSreason : CD
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”
Information Modeling Language
Patient
gender : CDdonor : BLV.I.P. : BL
Doctor
specialty : CDphone : TELprivileges: CV
Person
name : PNDOB : Dateaddress : AD
1
1..*
Encounter
type : CVtime : IVLTSreason : CD
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
Act.classCode :: CS (1..1) Mandatory
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..*)
Act.classCode :: CS (1..1) Mandatory
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"><!-- ******************************************************** CDA Header********************************************************-->
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
CDA Header CDA Body, Section, and Narrative Block
CDA Entries Ext'l Refs
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 Header CDA Body, Section, and Narrative Block
CDA Entries Ext'l Refs
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
<!-- ******************************************************** CDA Body********************************************************-->
<component><StructuredBody>
<!--
R-MIM
CDA Header CDA Body, Section, and Narrative Block
CDA Entries Ext'l Refs
CDA Section Narrative Block
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
<!-- ******************************************************** History of Present Illness section********************************************************--><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
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
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
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
2-nd Order 1 choice of 0-n Drug 0-1 Nursing
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
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? 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
Automated serializing of graphic designOrder
Definition
Performer
Author
Record target
Patient
Laboratory
Physician
Ordered test
Subject
Specimen
Automated serializing of graphic designOrder
Definition
Performer
Author
Record target
Patient
Laboratory
Physician
Ordered test
Subject
Specimen
Our example schemaThe subject
of the order
is a specimen
課程全部結束
top related