HL7 3

By: Dr.
Abbas Shojaee February, 2010

Faculty of paramedical sciences, Beheshti University of Medical Sciences
This presentation uses works of:

1. 2. 3.
4. 5.
Tim Benson W. Ted Klein Evangelos Milios Gunther Schadow Veli BICER
This is an introduction and it does not go into the details of concepts and interactions. Introduces RIM in detail Does not teach how to design models Does not cover details of project issues (e.g., tools, coordination, balloting, etc.) Contains a simple practice on how to design a software architecture for imposed security needs by HL7.
BUMS, Abbas Shojaee, Feb. 2010
1999, 2000 Health Level 7
January 24, 2000
Standards in Health care informatics

What is it? Why is needed?
HL7 evolution and history HL7 standard version 3.0

Describe the models in Version 3 Show how they are used to develop the HL7 message specifications that make up the standard?
Practicing development of a standard Practicing implementation of HL7 required functionalities for Security
January 24, 2000
Part I - Introduction
HL7, business problem, and how HL7 solves it What is Version 3? Why HL7 is making the move to Version 3
Part II - Technical Concepts

Background information
Part III - Methodology

Modeling process
January 24, 2000
What is a standard in medical informatics? Why and where is it needed? What urge them? The process of standard development in Medical Informatics?
January 24, 2000
Migration Towards a Wellness Model
Managing Visit
Managing Care
Clintons Reform
Managing Health
Initial
Fee-for-service, on-demand
Transitional
Capitated, case-based
Anticipated
Present time
Preventive, episodal
January 24, 2000
6
Client/Server, Internet, Multimedia

Centralized Computing (Batch)
Network Computing (RPC, ORBs, etc)
Digital
Dell
Micron
HP
Enterprise Computing (Client/Server)

January 24, 2000
Business Strategy & Motivation
Methodology, Measurement, Coordination
Planning & Enforcement

Modeling & Voting

January 24, 2000
Evolution and history The structure Organization and methodology
January 24, 2000
Health care environment is a complex environment and a language to describe it needs to accommodate this complexity HL7 is such a language The result of an ad hoc effort to make HIS information exchangeable The HL7 organization was founded in 1987
In June 1994 HL7 was designated as an ANSI accredited standards development organization (SDO)
January 24, 2000
10
Implementation Technology Specification
"Send as ASCII string in XML format"
Hierarchical Message Definition
"Discontinue pharmacy order"
ITS for XML
Data
HL7 Message Creation HL7-Conformant Application
Message Instance
HL7 Message Parsing HL7-Conformant Application
Data
January 24, 2000
11
To provide standards for the exchange, management and integration of data that supports clinical patient care and the management, delivery and evaluation of healthcare services. ... the complete life cycle of a standards specification -- development, adoption, market recognition, utilization and adherence.
January 24, 2000
12
A domain-specific, common protocol for the exchange of health care information.
Function
Communication
7 6 5 4 3 2 1
Application Presentation Session Transport Network Data Link Physical

1999, 2000 Health Level 7 January 24, 2000 13
ISO-OSI Communication Architecture Model

2.0 (1988) 2.1 (1990) 2.2 (1994) 2.3 (1997) 2.3.1 (1999) 2.4 (2000) 3.0
Prototype First standard Widely Adopted In operation Current ANSI standard In Ballot
January 24, 2000
14
The HL7 RIM (Reference Information Model) specifies the grammar of V3 messages and, specifically, the basic building blocks of the language (nouns, verbs, etc.), their permitted relationships, and Data Types. The RIM is not a model of health care. It is not a model of any message, either. Although it is healthcare-specific and it is used in messages.
Organization addr : BAG<AD> standardIndustryClassCode : CE
Place mobileInd : BL addr : AD directionsText : ED positionText : ED gpsText : ST
Patient confidentialityCode : CE veryImportantPersonCode : CE ManagedParticipation
ActRelationship
typeCode : CS id : SET<II> inversionInd : BL outboundRelationship statusCode : SET<CS> contextControlCode : CS Access LicensedEntity 0..n contextConductionInd : BL approachSiteCode : CD sequenceNumber : INT recertificationTime : TS Person targetSiteCode : CD 1 source priorityNumber : INT gaugeQuantity : PQ addr : BAG<AD> pauseQuantity : PQ Act Participation maritalStatusCode : CE checkpointCode : CS classCode : CS educationLevelCode : CE Entity typeCode : CS splitCode : CS Role moodCode : CS raceCode : SET<CE> classCode : CS functionCode : CD player joinCode : CS id : SET<II> disabilityCode : SET<CE> classCode : CS contextControlCode : CS ... determinerCode : CS negationInd : BL 0..1 code : CD 0..n livingArrangementCode : CE id : SET<II> sequenceNumber : INT id : SET<II> 0..n conjunctionCode : CS 1 negationInd : BL religiousAffiliationCode : CE code : CE code : CE playedRole negationInd : BL localVariableName : ST 1 derivationExpr : ST ethnicGroupCode : SET<CE> negationInd : BL quantity : SET<PQ> 0..n noteText : ED seperatableInd : BL text : ED addr : BAG<AD> time : IVL<TS> name : BAG<EN> inboundRelationship 0..n title : ST telecom : BAG<TEL> desc : ED modeCode : CE statusCode : SET<CS> statusCode : SET<CS> statusCode : SET<CS> awarenessCode : CE target scopedRole LivingSubject effectiveTime : GTS effectiveTime : IVL<TS> signatureCode : CE existenceTime : IVL<TS>... 0..n certificateText : ED activityTime : GTS 1 administrativeGenderCode : CE telecom : BAG<TEL> signatureText : ED 0..1 availabilityTime : TS birthTime : TS quantity : RTO source performInd : BL riskCode : CE ControlAct deceasedInd : BL scoper positionNumber : LIST<INT> ... 1 substitutionConditionCode ... : CE priorityCode : SET<CE> handlingCode : CE confidentialityCode : SET<CE>... deceasedTime : TS 1 target repeatNumber : IVL<INT> multipleBirthInd : BL 1 interruptibleInd : BL multipleBirthOrderNumber : INT WorkingList levelCode : CE organDonorInd : BL Employee outboundLink 0..n FinancialContract ownershipLevelCode : CE independentInd : BL 0..n jobCode : CE RoleLink paymentTermsCode : CE uncertaintyCode : CE jobTitleName : SC Material inboundLink typeCode : CS reasonCode : SET<CE> NonPersonLivingSubject jobClassCode : CE effectiveTime : IVL<TS> ... formCode : CE languageCode : CE strainText : ED salaryTypeCode : CE genderStatusCode : CE ManufacturedMaterial lotNumberText : ST expirationTime : IVL<TS> stabilityTime : IVL<TS> 0..n LanguageCommunication languageCode : CE modeCode : CE proficiencyLevelCode : CE preferenceInd : BL salaryQuantity : MO hazardExposureText : ED protectiveEquipmentText : ED InvoiceElement SubstanceAdministration routeCode : CE approachSiteCode : SET<CD> doseQuantity : IVL<PQ> rateQuantity : IVL<PQ> doseCheckQuantity : SET<RTO> maxDoseQuantity : SET<RTO> Observation value : ANY interpretationCode : SET<CE> methodCode : SET<CE> targetSiteCode : SET<CD> Procedure methodCode : SET<CE> approachSiteCode : SET<CD> targetSiteCode : SET<CD> modifierCode : SET<CE> unitQuantity : RTO<PQ,PQ> unitPriceAmt : RTO<MO,PQ> netAmt : MO factorNumber : REAL pointsNumber : REAL
Device
manufacturerModelName : SC softwareName : SC Container localRemoteControlStateCode... : CE capacityQuantity : PQ alertLevelCode : CE heightQuantity : PQ lastCalibrationTime : TS diameterQuantity : PQ capTypeCode : CE separatorTypeCode : CE barrierDeltaQuantity : PQ bottomDeltaQuantity : PQ
DiagnosticImage subjectOrientationCode : CE PatientEncounter preAdmitTestInd : BL admissionReferralSourceCode : CE lengthOfStayQuantity : PQ dischargeDispositionCode : CE specialCourtesiesCode : SET<CE> specialAccommodationCode : SET<CE> acuityLevelCode : CE PublicHealthCase detectionMethodCode : CE transmissionModeCode : CE diseaseImportedCode : CE Diet energyQuantity : PQ carbohydrateQuantity : PQ Supply quantity : PQ expectedUseTime : IVL<TS>
Account name : ST balanceAmt : MO currencyCode : CE interestRateQuantity : RTO<MO,PQ> allowedBalanceQuantity : IVL<MO>
FinancialTransaction DeviceTask parameterValue : LIST<ANY> amt : MO creditExchangeRateQuantity : REAL debitExchangeRateQuantity : REAL
RIM 2.01 July 17,2003
16
Large pictorial representation of the clinical data (domains) Identifies the life cycle of events that a message or groups of related messages will carry. Shared model between all the domains and as such is the model from which all domains create their messages. Explicitly representing the connections that exist between the information carried in the fields of HL7 messages
17
Specifies the grammar of HL7 messages The RIM backbone has just three core classes and a number of permitted relationships between them. Specialization
the basic building blocks of the language their permitted relationships.
Each class has a predefined set of attributes

HL7 V3 uses a graphical representation, called Refined Message Information Model (RMIM) to display the structure of a message as a colorcoded diagram.
specializations are only shown explicitly in the RIM when they add additional attributes to the general class
18
ActRelationship typeCode : CS inversionInd : BL outboundRelationship contextControlCode : CS 0..n contextConductionInd : BL sequenceNumber : INT 1 source priorityNumber : INT pauseQuantity : PQ Act Participation checkpointCode : CS classCode : CS Entity typeCode : CS splitCode : CS Role moodCode : CS classCode : CS functionCode : CD player joinCode : CS id : SET<II> classCode : CS contextControlCode : CS ... determinerCode : CS negationInd : BL 0..1 code : CD 0..n id : SET<II> sequenceNumber : INT 0..n id : SET<II> conjunctionCode : CS 1 negationInd : BL code : CE playedRole code : CE negationInd : BL localVariableName : ST 1 derivationExpr : ST negationInd : BL quantity : SET<PQ> 0..n noteText : ED seperatableInd : BL text : ED addr : BAG<AD> time : IVL<TS> name : BAG<EN> inboundRelationship 0..n title : ST telecom : BAG<TEL> desc : ED modeCode : CE statusCode : SET<CS> statusCode : SET<CS> statusCode : SET<CS> awarenessCode : CE target scopedRole effectiveTime : GTS effectiveTime : IVL<TS> signatureCode : CE existenceTime : IVL<TS> ... 0..n certificateText : ED activityTime : GTS 1 telecom : BAG<TEL> signatureText : ED 0..1 availabilityTime : TS quantity : RTO source performInd : BL riskCode : CE scoper positionNumber : LIST<INT> ... 1 substitutionConditionCode ... : CE priorityCode : SET<CE> handlingCode : CE confidentialityCode : SET<CE> 1 target repeatNumber : IVL<INT> interruptibleInd : BL levelCode : CE outboundLink 0..n independentInd : BL 0..n RoleLink uncertaintyCode : CE inboundLink typeCode : CS reasonCode : SET<CE> effectiveTime : IVL<TS> ... languageCode : CE
19
The RIM defines a set pre-defined Attributes for each class These are the only ones allowed in HL7 messages. Denoting attributes? E.g. Act.id Each attribute has a specified Data Type. These Attributes and Data Types become tags in HL7 XML messages.
20
One common data type is the Instance Identifier (e.g. id), which is used to give unique identity to people, persons, organizations, things and information objects. The datatype for id is II(instance identifier)
II: Object Identifier (OID) Universal Unique Identifier (UUID)
21
ClassCode to identify the type of Act

Code to further identify a classcode

to specify precisely what the class means at a leaf level of granularity. HL7 uses two main types of code.
1. 2. The first type covers the specialized codes used for structural attributes and are defined by HL7 itself. The second type covers externally defined terms and codes such as SNOMED CT (Clinical Terms).
An structural attribute Obligatory
22
Used to specify more precisely what each RIM class means when used in a message. For example, Act has a class code and a mood code.
The class code states what sort of Act this is, such as an observation, an encounter, or the administration of a drug. Mood is analogous to the tense of a verb. Mood code indicates whether an Act has happened (an event), or is a request for something to happen, or a goal or even a criterion. "weight = 100kg" is an observation event; "measure weight daily" is a request; "reduce weight to 80Kg" is a goal "if weight is greater than 80Kg" is a criterion.
For example,
23
Every happening is an Act, analogous to a verb in English. Each Act may have any number of Participations, in Roles, played by Entities. These are analogous to nouns. Act
Kind of act (what happens) Actor (who performs) Subject whom is affected (e.g. patient) Where (location) When (time) How (manner) Why (Reasons ) What for (motives)
Each Act may also be related to other Acts, via ActRelationships.
24
Acts.classCode specifies the type

of act.
Event Observation Notification
Times Lets discuss act specializations

Observation, Procedure, Substance Administration, Supply, and ActivityTime EffectivityTime
Acts.modeCode specifies the

tense of act:

Acts.StatusCode
New Active Completed Canceled Aborted
Fact (indicative mood) =EVN Command (imperative mood) = RQO Question (interrogative mood) Wish (optative mood) Conditionality (Subjunctive mood) Promise = PRMS Proposal = PRP
PatientEncounter.
25
Entity is anything, which has or will have existence.

Living Non living Abstract
Structural attributes
Individual instance Collection Generic class
Entity.classCode identifies the represented concept. Entity.determinerCode identifies the type of representation
Either plays a Role or defines the scope for a Role Every Role is played just by a single Entity Some attributes of an Entity, are also found in the Role class. These include id, code, name, addr (address), telecom,
statusCode, and quantity
What is the rule, how can I choose using Entity and Role overlapping attributes?
Living subject
Person NonPersonLivingSubject
Material Places Organization
Role is defined as a competency of an Entity playing the Role Samples:

Whar are Roles for people What are Roles for inanimate objects
People, such as patient, practitioner, or employee Places, such as hospital, home, clinic, or place of birth Organizations, such as care provider, employer, or supplier
The most important Role specialization is Patient.
Things, such as drug, instrument, or computer system Responsible entities, such as parent, employer, or manufacturer
Are used to constrain and verify conformance to profiled HL7 Version 3 Refined Message Information Models (RMIMs). Expresses the data content needed in a specific clinical or administrative context
32
Explicit connection between core classes are needed
ActRelationship:
To link Acts together, from a Source Act to a Target Act ActRelationship .typeCode to specify the type of association
Composition comprises entries Discharge summary documents a hospital visit Test report fulfills a test request Discharge summary refers to a referral Final report replaces a preliminary report
Role Link:
Role Link is a relationship between two Roles.
Participation:
It shows how an Entity, in a particular Role, functions during the scope of an Act Participants (entities) perform in an act as either actor (active) or target (passive) A participant in particular role, can contribute to an act in many ways. (e.g. a surgen) Participation.typeCode specifies the type of association between an Act and each participating Role
Performer of act (surgeons, observers, practitioners) Subject of act, such as the patient Location of act Author, informant, addressee, or information recipient
Classification: ordered system of concepts related to a domain Clinical terminology: terminology needed to record all important aspects of health care in standardized form
35
Entity Act
0..* participant 0..*participant scopedRole / participation Role type Code *: <= ParticipationType classCode *: <= ROL functionCode: CD CWE [0..1] <= ParticipationFunction id: SET<II> [0..*] contextControlCode: CS CNE [0..1] <= ContextControl code: CE CWE [0..1] <= RoleCode sequenceNumber: INT [0..1] negationInd: BL [0..1] negationInd: BL [0..1] addr: BAG<AD> [0..*] noteText: ED [0..1] telecom: BAG<TEL> [0..*] time: IVL<TS> [0..1] statusCode: SET<CS> CNE [0..*] <= RoleStatus modeCode: CE CWE [0..1] <= ParticipationMode effectiveTime: IVL<TS> [0..1] awarenessCode: CE CWE [0..1] <= TargetAwareness certificateText: ED [0..1] signatureCode: CE CNE [0..1] <= ParticipationSignature quantity: RTO<QTY,QTY> [0..1] signatureText: ED [0..1] positionNumber: LIST<INT> [0..*] 0..* playedRole performInd: BL [0..1] 0..* act 0..1 playingEntity 0..1 scopingEntity classCode *: <= ACT m oodCode *: <= EVN id: SET<II> [0..*] code: CD CWE [0..1] <= ActCode negationInd: BL [0..1] derivationExpr: ST [0..1] text: ED [0..1] statusCode: SET<CS> CNE [0..*] <= ActStatus effectiveTime: GTS [0..1] activityTime: GTS [0..1] availabilityTime: TS [0..1] priorityCode: SET<CE> CWE [0..*] <= ActPriority confidentialityCode: SET<CE> CWE [0..*] <= Confidentiality repeatNumber: IVL<INT> [0..1] interruptibleInd: BL [0..1] levelCode: CE CWE [0..1] <= ActContextLevel independentInd: BL [0..1] uncertaintyCode: CE CNE [0..1] <= ActUncertainty reasonCode: SET<CE> CWE [0..*] <= ActReason languageCode: CE CWE [0..1] <= HumanLanguage
Entity
classCode *: <= ENT de te r m ine r Code *: <= INSTANCE id: SET<II> [0..*] code: CE CWE [0..1] <= EntityCode quantity: SET<PQ> [0..*] name: BAG<EN> [0..*] desc: ED [0..1] statusCode: SET<CS> CNE [0..*] <= EntityStatus existenceTime: IVL<TS> [0..1] telecom: BAG<TEL> [0..*] riskCode: CE CWE [0..1] <= EntityRisk handlingCode: CE CWE [0..1] <= EntityHandling
sourceOf / targetOf
type Code *: <= ActRelationshipType inversionInd: BL [0..1] contextControlCode: CS CNE [0..1] <= ContextControl contextConductionInd: BL [0..1] sequenceNumber: INT [0..1] priorityNumber: INT [0..1] pauseQuantity: PQ [0..1] checkpointCode: CS CNE [0..1] <= ActRelationshipCheckpoint splitCode: CS CNE [0..1] <= ActRelationshipSplit joinCode: CS CNE [0..1] <= ActRelationshipJoin negationInd: BL [0..1] conjunctionCode: CS CNE [0..1] <= RelationshipConjunction localVariableName: ST [0..1] seperatableInd: BL [0..1]
0..* source
0..* target
Act
11/10/2002
36
Organization
classCode *: <= OR G de te r m ine r Code *: <= INSTANCE name: BAG<EN> [0..*] standardIndustryClassCode: CE CWE [0..1] <= OrganizationIndustryClass 0..1 researchSponsor
ObservationEvent ResearchSubject
0..* sponsoredSubject classCode *: <= RESBJ 0..* researchSubject id: SET<II> [0..*] subject code: CE CWE [0..1] <= RoleCode type Code *: <= SBJ addr: BAG<AD> [0..*] telecom: BAG<TEL> [0..*] statusCode: SET<CS> CNE [0..*] <= RoleStatus effectiveTime: IVL<TS> [0..1] 0..* subjectOf classCode *: <= OBS m oodCode *: <= EVN id*: II [1..1] code*: CD CWE [1..1] <= Ob servationType text: ED [0..1] statusCode*: CS CNE [1..1] <= completed effectiveTime*: IVL<TS> [1..1] confidentialityCode: SET<CE> CWE [0..*] <= Confidentiality
component
type Code *: <= C OMP 0..* observationEvent
0..1 subjectPerson
Person
classCode *: <= PSN de te r m ine r Code *: <= INSTANCE id: SET<II> [0..*] code: CE CWE [0..1] <= EntityCode name: BAG<EN> [0..*] riskCode: CE CWE [0..1] <= EntityRisk handlingCode: CE CWE [0..1] <= EntityHandling administrativeGenderCode: CE CWE [0..1] <= AdministrativeGender birthTime: TS [0..1] deceasedTime: TS [0..1] maritalStatusCode: CE CWE [0..1] <= MaritalStatus educationLevelCode: CE CWE [0..1] <= EducationLevel disabilityCode: SET<CE> CWE [0..*] <= PersonDisab ilityType livingArrangementCode: CE CWE [0..1] <= LivingArrangement religiousAffiliationCode: CE CWE [0..1] <= ReligiousAffiliation raceCode: SET<CE> CWE [0..*] <= Race ethnicGroupCode: SET<CE> CWE [0..*] <= Ethnicity
ObservationEvent
classCode *: <= OBS m oodCode *: <= EVN id*: II [1..1] code*: CD CWE [1..1] <= Ob servationType statusCode: CS CNE [1..1] <= completed effectiveTime*: IVL<TS> [0..1] confidentialityCode: SET<CE> CWE [0..*] <= Confidentiality
37
A model is a collection of subject areas, scenarios, classes, attributes, use cases, actors, trigger events, interactions, etc. that depict the information needed to specify HL7 Version3 messages. HL7 models are further divided into four specific models - a use case model, an information model, an interaction model, and a message design model.
Decomposition
Divide-and-conquer
Abstraction
Chunking the information
Hierarchy
Increasing semantic content of individual chunks of information through reuse
40
Captures healthcare requirements
Use Case Model
Defines scope for TSC approval
Specifies data and its semantics
Information Model
Specifies major state transitions Specifies vocabulary for domains Defines information flows
Interaction Model
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

41
HL7 Models
Use Case Model
Describes specific situations in which communication between healthcare entities is needed.
Information Model
A detailed and precise definition for the information from which all data content of HL7 messages are drawn. Classes, Attributes, and Relationships
State Transition Models for certain selected classes. Data Types and Constraints.
Documented in the Reference Information Model, the Domain Information Model, and the Message Information Model
Root of all information models. Provides a static view of the information. A HL7-wide common reference model that is result of the combined consensus view of information and integrates all Technical Committees domain views. HL7 development methodology calls for creation of small subset of the RIM - called Domain specific Information Model or DIM and incremental refining to achieve Problem-area-specific design models
Foundation Classes
Acts Entities Roles
Communication Infrastructure
Core Infrastructure Message Communications Control Structured Documents
Interaction Model
Specifies all Trigger Events and Message Flows. Specifies the Application Roles.
Each Interaction consists of:

Trigger event
Initiators of Interactions.
Message ID
Each interaction sends one particular message
Sender role
Receiver role
When trigger event detected, message is sent Receiver responsibility
Encounter_manager : AR_Encounter_
Encounter_tracker : AR_Encounter_
Encounter_archivist : AR_Encounter_
1: schedule_encounter
Application Role 2: delete_scheduled_encounter identifies an information management responsibility for one of the subject classes. 3: admit_patient Responsibilities typically are: Creator, Manager, Tracker and Archivist. 4: admit_patient
Interactio n
5: admit_patient
Healthcare applications are assumed to take on one or more application roles.
Interaction ID Interaction Name Trigger Event Name Event Dependency
PA231 Send Registration to Trackers Patient Registers for Encounter Account must be in the unregistered or pregistered state A01 Encounter Manager Encounter Tracker
PA232 Send Registration to Archivists Patient Registers for Encounter Account must be in the unregistered or pregistered state A02 Encounter Manager Encounter Archivist
Message ID Sender Receiver Receiver Responsibility
Message Model
Domain Information Model Reference Information 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..* Encounter_practitioner is_associated_with participation_type_cd 1..* Exactly one occurrence 1 participates_as has_as_participant 1 1 Individual_healthcare_practitioner Patient_encounter is_a_role_of id : TII 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
Use Case Model

Hierarchical
Message
Interaction Model
Description
Message Information Model
The RIM must first be refined by subsetting and constraining it

Create a MIM with RIM classes needed Develop an R-MIM from these classes
Collection of classes with some constraints Collection of attributes and associations to support the R-MIM
Person_name effective_dt cd nm purpose_cd termination_dt type_cd 0..* is_for 1 has
Stakeholder addr credit_rating_cd email_address_txt phon type_cd real_id : SET<RWII> id : SET<II>
participates_as_primary_in 0..* has_as_primary_participant 1 0..* participates_as_secondary_in 1 has_as_secondary_participant
Stakeholder_affiliation affiliation_type_cd desc effective_dt termination_dt
has_as_a_subdivision 0..1 Person Organization 0..* is_a_subdivision_of organization_name_type_cd organization_nm standard_industry_class_cd
Fewer attributes
BUMS, Abbas
birth_dttm birthplace_addr citizenship_country_cd confidentiality_constraint_cd deceased_dttm deceased_ind disability_cd 0..* participates_as_primary_in education_level_cd Stakeholder Person_name ethnic_group_cd 1..1 has_as_primary_participant Stakeholder_affiliation addr : ST nm : ST administrative_gender_cd participates_as_secondary_in email_address_txt : TEL 0..* affiliation_type_cd : CD type_cd : CD language_cd id : SET<II> 1..1 has_as_secondary_participant marital_status_cd military_branch_of_service_cd 0..* is_for military_rank_nm military_status_cd nationality_cd race_cd religious_affiliation_cd has_as_a_subdivision 1..1 student_cd has very_important_person_cd 0..1 status_cd Person Organization 0..* ambulatory_status_cd organization_nm : ST id education_level_cd : CD is_a_subdivision_of hispanic_ind birth_order_nbr 1..1 1..1 proposes 1..1 living_arrangement_cd has_as_role sponsors living_dependency_cd multiple_birth_ind Shojaee, Feb. 20100..* is_role_of organ_donor_ind
RIM content
MIM content
(a proper subset of the RIM)
Constrain cardinality on Associations Constraints on Attributes
Classes are duplicated for different uses May modify the Inheritance structure
Some specializations may subsume the generalization Always inherit downwards to specializations
Some may be left out Sub-components may be individually constrained
Person_name nm : ST type_cd : CD 0..* is_for
0..* participates_as_primary_in Stakeholder 1..1 has_as_primary_participant Stakeholder_affiliation addr : ST email_address_txt : TEL participates_as_secondary_in 0..* affiliation_type_cd : CD id : SET<II> 1..1 has_as_secondary_participant
1..1 has Person education_level_cd : CD 1..1 has_as_role 0..* is_role_of Voting_member draft_level_voting_ind : BL 1..1 standard_level_voting_ind : BL casts sponsors
has_as_a_subdivision 0..1 Organization 0..* organization_nm : ST is_a_subdivision_of 1..1 1..1 proposes
Proposed_item ballot_period_tmr : IVL<TS> proposed_by content_txt : ED standard_level_ind : BL 0..* 1..1 receives_votes
0..* sponsored_by Individual_representative dues_current_ind : BL Organizational_representative
cast_by
Ballot 0..* comments_txt : ST dttm : TS vote_cd : CV
votes_on 0..*
MIM
Person_name is_for nm : ST type_cd : CD 0..1 is_for 0..*
has_as_secondary_participant 0..* 0..* participates_as_secondary_in has_as_primary_participant
Stakeholder_affiliation affiliation_type_cd : CD
1..1 has 1..1 Person_as_Committee_contact email_address_txt : TEL participates_as_primary_in has_as_a_subdivision 0..1 1..1 Organization_as_Committee organization_nm : ST 1..1 0..* is_a_subdivision_of
has
1..1
Person_as_Voter education_level_cd : CD email_address_txt : TEL 1..1 has_as_role is_role_of 0..* Voting_member draft_level_voting_ind : BL 1..1 standard_level_voting_ind : BL casts
proposes
proposed_by Organization_as_HL7_member organization_nm : ST email_address_txt : TEL sponsors 0..1 0..* Proposed_item ballot_period_tmr : IVL<TS> content_txt : ED standard_level_ind : BL 1..1 receives_votes
Individual_representative dues_current_ind : BL
0..* sponsored_by Organizational_representative
cast_by
votes_on Ballot 0..* 0..* comments_txt : ST dttm : TS vote_cd : CV
RMIM
Person_name is_for nm : ST type_cd : CD 0..1
has_as_secondary_participant 0..* 0..* participates_as_secondary_in has_as_primary_participant
Stakeholder_affiliation affiliation_type_cd : CD
is_for
0..*
1..1 has 1..1 Person_as_Committee_contact email_address_txt : TEL
has
1..1
Person_as_Voter education_level_cd : CD email_address_txt : TEL 1..1 has_as_role is_role_of 0..* Voting_member draft_level_voting_ind : BL 1..1 standard_level_voting_ind : BL casts
participates_as_primary_in has_as_a_subdivision 0..1 1..1 Organization_as_Committee organization_nm : ST 1..1 0..*
2a
is_a_subdivision_of
proposes
proposed_by Organization_as_HL7_member organization_nm : ST email_address_txt : TEL sponsors 0..1 0..* Proposed_item ballot_period_tmr : IVL<TS> content_txt : ED standard_level_ind : BL
1..1 receives_votes
Individual_representative dues_current_ind : BL
0..* sponsored_by Organizational_representative
cast_by
votes_on Ballot 0..* 0..* comments_txt : ST dttm : TS vote_cd : CV
A method of encoding and sending HL7 messages. XML represents one of several ITS to be developed
MSH|^~\&|LABGL1||DMCRES||199812300100||ORU^R01|LABGL1199510221838581|P|2.3 |||NE|NE PID|||6910828^Y^C8||NewmanÂlfredÊ||19720812|M||W|25 Centscheap Ave^^ WhatmeworryÛT^85201^^P||(555)777-6666|(444)677-7777||M||773789090 OBR||110801^LABGL|387209373^DMCRES|18768-2^CELL COUNTS+DIFFERENTIAL TESTS (COMPOSITE)^LN|||199812292128||35^ML|||||||IN2973^Schadow^Gunther^^^^MDÛPIN ||||||||||Ônce||||||CA20837^Spinosa^John^^^^MDÛPIN OBX||NM|4544-3^HEMATOCRIT (AUTOMATED)^LN||45||39-49 ||||F|||199812292128||CA20837 OBX||NM|789-8ÊRYTHROCYTES COUNT (AUTOMATED)^LN||4.94|10*12/mm3 |4.30-5.90||||F|||199812292128||CA20837
<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > <id root="" /> <code code="11488-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" /> <statusCode code="completed" /> <effectiveTime value="20030506230256" /> <confidentialityCode code="N" /> <component> <documentBody> <component> <documentSectionEvent> <code code="10164-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" /> <text /> </documentSectionEvent> </component> <component> <documentSectionEvent> <code code="11384-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" /> <text /> <component> <observation> <id root="2.16.840.1.113883.9876.368.2" /> ..
<act classCode=ACT moodCode=> <id root=1.3.6.1.4.1.12009.3 extension=A1234/> <code code=... codeSystem=2.16.840.1.113883.6.1/> <participant typeCode=> <participant classCode=ROL> <id root=1.3.6.1.4.1.12009.4 extension=1234567-8/> <code code= codeSystem=2.16.840.1.113883.6.21/> <playingEntity classCode=ENT> <name>...</name> </playingEntity> <scopingEntity classCode=ENT> <name>...</name> </scopingEntity> </participant> </participant> <sourceOf typeCode=REL> <target classCode=ACT> <id root=1.3.6.1.4.1.12009.3 extension=A1235/> </target> </sourceOf> </act>
67
Organization
classCode *: <= OR G de te r m ine r Code *: <= INSTANCE name: BAG<EN> [0..*] standardIndustryClassCode: CE CWE [0..1] <= OrganizationIndustryClass 0..1 providerOrganization
Patient
0..* patient
ObservationEvent
classCode *: <= OBS m oodCode *: <= EVN id*: II [1..1] code*: CD CWE [1..1] <= Ob servationType text: ED [0..1] statusCode*: CS CNE [1..1] <= completed effectiveTime*: IVL<TS> [1..1] confidentialityCode: SET<CE> CWE [0..*] <= Confidentiality
classCode *: <= PAT 0..* patient id: SET<II> [0..*] subject code: CE CWE [0..1] <= RoleCode addr: BAG<AD> [0..*] type Code *: <= SBJ telecom: BAG<TEL> [0..*] awarenessCode: CE CWE [0..1] <= TargetAwareness statusCode: SET<CS> CNE [0..*] <= RoleStatus effectiveTime: IVL<TS> [0..1] confidentialityCode: CE CWE [0..1] <= Confidentiality veryImportantPersonCode: CE CWE [0..1] <= PatientImportance 0..* healthCareProvider 0..1 patientPerson
component
type Code *: <= C OMP 0..* observationEvent
Person
classCode *: <= PSN de te r m ine r Code *: <= INSTANCE id: SET<II> [0..*] code: CE CWE [0..1] <= EntityCode name: BAG<EN> [0..*] riskCode: CE CWE [0..1] <= EntityRisk handlingCode: CE CWE [0..1] <= EntityHandling administrativeGenderCode: CE CWE [0..1] <= AdministrativeGender birthTime: TS [0..1] deceasedTime: TS [0..1] maritalStatusCode: CE CWE [0..1] <= MaritalStatus educationLevelCode: CE CWE [0..1] <= EducationLevel disabilityCode: SET<CE> CWE [0..*] <= PersonDisab ilityType livingArrangementCode: CE CWE [0..1] <= LivingArrangement religiousAffiliationCode: CE CWE [0..1] <= ReligiousAffiliation raceCode: SET<CE> CWE [0..*] <= Race ethnicGroupCode: SET<CE> CWE [0..*] <= Ethnicity
ObservationEvent
classCode *: <= OBS m oodCode *: <= EVN id*: II [1..1] code*: CD CWE [1..1] <= Ob servationType statusCode: CS CNE [1..1] <= completed effectiveTime*: IVL<TS> [0..1] confidentialityCode: SET<CE> CWE [0..*] <= Confidentiality
68
<observationEvent classCode=OBS moodCode=EVN> <id root=1.3.6.1.4.1.12009.3 extension=A1234/> <code code=... codeSystem=2.16.840.1.113883.6.1/> <subject typeCode=> <patient classCode=ROL> <id root=1.3.6.1.4.1.12009.4 extension=1234567-8/> <code code= codeSystem=2.16.840.1.113883.6.21/> <patientPerson classCode=PSN> <name><given>John</given><family>Doe</family></name> </patientPerson> <providerOrganization classCode=ORG> <name>St., Josephs Hospital</name> </providerOrganization> </patient> </subject> <component typeCode=REL> <observationEvent classCode=ACT> <id root=1.3.6.1.4.1.12009.3 extension=A1235/> </observationEvent> </component> </observationEvent>
69
Clinical Document Architecture
CDA: document model using XML tags RIM: defines the tags Why CDA is needed:
Difference between documents and databases Documents carry meta data persistence, stewardship, authentication, wholeness, and human readability.
CDA evolution history
74
exchange model for clinical documents

Discharge Summary, Imaging Report, Admission & Physical, Pathology Report
Based on XML, HL7, RIM and coded vocabularies, CDA makes documents both
Machine readable Human readable
75
Users set their own level of compliance Minimal CDA: High end CDA:
small number of XML-encoded metadata fields Body in pdf, doc or scanned image file
RIM Controlled vocabulary (LOINC, SNOMED, ICD,
76
CDA structure
Limitations of Version 2.3 Benefits of Version 3 Version 3 Statement of Principles Goals Mission
Complex integration: at least 2-4 months to install HL7 interfaces
Problem Honest misunderstanding of specifications
Cause Different implicit information models

No vocabulary to describe conformance concepts
Misleading conformance claims
79
Unmeasurable progress Unpredictable results Metastasizing optionality
Outcome...
Past V2 Process
Patient Care ADT/ Financ e
MnM
Orders Control / Home Health
80
Implicit information model, not explicit Events not tightly coupled to profiles Need for controlled vocabularies Limited to a single encoding syntax No explicit support for object technologies No explicit support for security functions Optionality is ubiquitous and troublesome
81
Reduces optionality: results in more specific messages Uncovers hidden assumptions about application boundaries
Facilitates defining clear, fine-grained, conformance claims
HL7 V3.0 Certified
82
Deals with complexity of the HC environment:

Facilitates
integration of heterogeneous systems

best-of-breed
Increases choices of innovative solutions
Provides support for legacy systems Allows reliable verification of vendors conformance claims
24, 2000
83
Provides improved protocol for interconnecting heterogeneous systems installation effort
Reduces

reduces site-specific negotiations

simplifies interface programming
Promotes
vendor specialization by allowing segmentation of product lines into niche market spaces
84
Provide a framework for coupling events, data elements and messages Improve clarity and precision of specification Improve adaptability of standards to change Begin to approach plug and play
85
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
86
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
87
To bring modern software engineering practices, such as Object Oriented Analysis and Design and formal modeling, to the standards development process To bring the highest level of quality, understandability, and flexibility to a messaging standard
Incorporate concept abstractions and behavior modeling using roles in a rigorous set of work products
Express the standard in widely accepted UML notation
88
Chapters 2 and 8
Common Specs
ChapterChapterChapterSpecific Specific Specific Specs Specs Specs
Chapters 3, 4, 6, ...
Segment s and Fields
Trigger Event and Message s
89
Trigger events
Actions or occurrences
Messages
Information content
Segments
Repeating structures
Data elements
Data representation
90
HL7 Referenc e Model Commo n Specs
Chapter Specific Specs

*Future Considerati on
Use Case Model
Information Model
Interaction Model
Message Model
Implementable Message Implementable Specification Implementable Message 2-nd Order Message Specification 1 choice of XML/ER7/ Specification 0-n Drug OLE/CORBA 0-1 Nursing EDIFACT*
91
The HL7 2.x specifications have:

Segments that imply information entities Events that indicate implied behaviors Descriptive content that suggests use cases
but never formally documents these
Version 3 seeks to formalize this by applying object analytic methods and style
to to to to improve the internal consistency of HL7 provide sound semantic definitions enable future architectures produce an evolution not a revolution
Done by applying MODELING to the HL7 process

92
By demanding Dispense Manage Perform Lab Review Abstractions: analysis of the Medications Tests Utilization Version Care 2.x focused its requirements and Activities energies at the information (Use Case communication level and content, Version 3 Model) covered the other assures Account Encounter Provider Patient abstractions only loosely in Order Objects consistency in and the specifications. (Information enhances the value Model) of the resulting messages. HL7 message HL7 message Communicatio n (Interaction
and Message Models)
Finance
ADT
Pharmacy
93
Use case model

Hierarchy of tasks and actors
Message design model

Refined Message Information Model (R-MIM) Abstract message definitions (HMDs)
Interaction model
Trigger events, abstract messages & application profiles
Vocabulary
Information model
Classes, relationships, states, and lifecycles
Domain definitions Representations and mappings
Implementation
Implementation Technology Specification (ITS)

94
Concepts
Modeling
January 24, 2000
95
Process:
Method: Model: subject
Operation
Activities leading to the orderly

construction of the models An approach to problem solving Abstract representation of a
Attributes (Data)
Operation
Object:
Domain specific concept

January 24, 2000
96
Domain Analysis
Requirements Analysis
Release 3.0
Message Design
Message Specification
January 24, 2000 97
Decomposition
Divide-and-conquer
Abstraction
Chunking the information
Hierarchy
Increasing semantic content of individual chunks of information through reuse
January 24, 2000
98
Applying analysis techniques leads to solutions to integrate components Modeling provides the framework for the analysis steps and products Object Oriented Analysis and Modeling form the basis of the standard techniques adopted for Version 3
January 24, 2000
99
The deliverables are expressed as models Each model leads to greater understanding of areas that influence content, structure, and behavior of messages Messages are defined when the models are merged The HL7 standard message specification will be derived from the models Models are expressed in UML
January 24, 2000
10 0
Process Overview
Model Deliverables and Phases Generation of Messages
Process in Detail
Methodology Activities Coordination of Parallel Committee Projects (Harmonization)
January 24, 2000
10 1
Tasks Deliverables Phases
January 24, 2000
102
Analysis
Requirements Analysis Domain Analysis
Use Case Model (UCM) Information Model (RIM & DIM) Vocabulary Domain Specification
Design
Component and Object Interaction Model (IM) Message Information Model Interaction Design (MIM) Message Design
Voting and Publishing Implementation Guide

Technology
Hierarchical Message Description (HMD)
Implementation Technology 1999, 2000 Health Level 7 January 24, 2000
10 3
Use Case Model
Captures healthcare requiremen
Defines scope for TSC approval

Specifies data and its
Information Model

semantics
Specifies major state
Interaction Model
transitions Defines information flows Specifies vocabulary for Defines communication roles domains Forms basis for conformance c
Defines message contents
Message Specification Apply constraints to the

information model and
vocabulary
January 24, 2000
10 4
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
January 24, 2000
10 5
Analysis
Requirements Analysis Domain Analysis
Design
Interaction Design Message Design
Voting
Approval

Domain Information Model (DIM) Hierarchical Message Descriptions (HMD)
Use Case Model (UCM)

RIM
Interaction Model (IM)
Ballots
Reference Model Repository

January 24, 2000
10 6
Develop Scope Create Use Cases
Information Model Use Case Model

Spec DIM Spec Class Diagram State Diagram UCM Spec Use Case Diagram Spec
Draw initial contents from RIM

Model new concepts
Identify Actors & Events

Define Trigger Events Define Application Roles Define Interactions Create Conformanc e Claims
Harmonize with RIM
Interaction Model
Spec
Message Design
Develop Message Information Mode Develop Message Object Diagram Specify HMD
Inter Spec Interaction Diagram
2-nd Order h//mt:50d 1 choice of 0-n Drug 0-1 Nursing
January 24, 2000
10 7
Reference Information Model
Domain Information Model
Use Case Model
Interaction Model
Message Information 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..*
Encounter_practitioner is_associated_with participation_type_cd 1..* Exactly one occurrence
1 participates_as 1 Individual_healthcare_practitioner is_a_role_of id : TII
has_as_participant
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

1999, 2000 Health Level 7 January 24, 2000 10 8
Implementation Technology Specifications
"Send as ASCII string in XML format"
Hierarchical Message Definition
"Discontinue pharmacy order"
ITS
Data
HL7 Message Creation
Message Instance
HL7 Message Parsing
Data
HL7-Conformant Application
HL7-Conformant Application
10 9
January 24, 2000
Internal consistency - enforced in models Sound definitions - captured in a repository Enables variety of implementation technologies
ranging from ASCII to ORBs and EDIFACT to XML
Eliminates rampant optionality in the messages

reduces implementation effort
Application roles are a basis for component functional specifications Provides verifiable conformance claims
January 24, 2000
11 0
Jacobson, I. Et Al, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, Reading, MA, 1994. Rumbaugh, J. Et Al, Object-Oriented Modeling and Design, Prentice Hall International, Englewood Cliffs, NJ, 1991. Booch, G., Object-Oriented Analysis and Design with Applications, 2nd ed., The Benjamin/Cummings Publishing Company, Inc., Redwood City, CA, 1994.
January 24, 2000
11 1
White, I., Using the Booch Method. A Rational Approach, The Benjamin/Cummings Publishing Company, Inc. Redwood City, CA, 1994. M. Fowler, UML Distilled. Applying the Standard Object Modeling Language, Addison-Wesley, Reading, MA, 1997. Vaskevitch, D., Client/Server Strategies, IDG Books, San Mateo, CA, 1993. Taylor, D.A., Object-Oriented Technology: A Managers Guide, Addison-Wesley, Reading, MA, 1990. Taylor, D.A., Business Engineering with Object Technology, John Wiley & Sons, Inc.. New York, NY, 1995.
January 24, 2000
11 2
Object Magazine, SIGS Publication Distributed Object Computing (DOC) Journal of Object-Oriented Programming (JOOP)
January 24, 2000
11 3

HL7 3

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

HL7 3

Diunggah oleh

Hak Cipta:

Format Tersedia

By: Dr.

Abbas Shojaee February, 2010

This presentation uses works of:

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

Standards in Health care informatics

HL7 evolution and history HL7 standard version 3.0

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

Part II - Technical Concepts

Part III - Methodology

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

January 24, 2000

1999, 2000 Health Level 7

Migration Towards a Wellness Model

Client/Server, Internet, Multimedia

Enterprise Computing (Client/Server)

January 24, 2000

Business Strategy & Motivation

Methodology, Measurement, Coordination

Planning & Enforcement

Modeling & Voting

January 24, 2000

Evolution and history The structure Organization and methodology

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

Implementation Technology Specification

"Send as ASCII string in XML format"

Hierarchical Message Definition

"Discontinue pharmacy order"

ITS for XML

HL7 Message Creation HL7-Conformant Application

HL7 Message Parsing HL7-Conformant Application

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

A domain-specific, common protocol for the exchange of health care information.

Application Presentation Session Transport Network Data Link Physical

ISO-OSI Communication Architecture Model

BUMS, Abbas Shojaee, Feb. 2010

1999, 2000 Health Level 7

January 24, 2000

BUMS, Abbas Shojaee, Feb. 2010

Organization addr : BAG<AD> standardIndustryClassCode : CE

Place mobileInd : BL addr : AD directionsText : ED positionText : ED gpsText : ST

Patient confidentialityCode : CE veryImportantPersonCode : CE ManagedParticipation

Account name : ST balanceAmt : MO currencyCode : CE interestRateQuantity : RTO<MO,PQ> allowedBalanceQuantity : IVL<MO>

FinancialTransaction DeviceTask parameterValue : LIST<ANY> amt : MO creditExchangeRateQuantity : REAL debitExchangeRateQuantity : REAL

RIM 2.01 July 17,2003

BUMS, Abbas Shojaee, Feb. 2010

BUMS, Abbas Shojaee, Feb. 2010

Each class has a predefined set of attributes

BUMS, Abbas Shojaee, Feb. 2010