Transcript Slide 1

NOTES:
Action items can be found on slide 27
Agenda Items for Feb 23 meeting are on the next page
Key changes in the document:
P. 2: agenda for next meeting
Pp. 17-19: discussion with Lloyd on what is a DAM and the techniques to use
Pp. 38-68: description of the HDF DAP approach for a DAM, including artefacts
Care Plan Team Meeting
(As updated during meeting)
André Boudreau ([email protected])
Laura Heermann Langford ([email protected])
2011-02-16 (No. 2)
2011-02-09 (No. 1)
HL7 Patient Care Work group
Agenda items for Feb. 23rd
• Validate the approach
• Identify the business / clinical situations that we
want the Care Plan interoperability to address
• Review what we have on hand (inventory of use
cases, storyboards)
• Decide on next steps
Page 2
Participants- Meetg of 2011-02-16
Name
email
Country
Yes
No
André Boudreau
[email protected]
CA
Yes
Laura Heermann Langford
[email protected]
US
Yes
Stephen Chu
[email protected]
AU
Yes
Peter MacIsaac
[email protected]
AU
No
David Rowed
[email protected]
AU
No
Adel Ghlamallah
[email protected]
CA
William Goossen
[email protected]
NL
No
Anneke Goossen
[email protected]
NL
No
Ian Townsend
[email protected]
UK
No
Charlie Bishop
[email protected]
UK
No
Rosemary Kennedy
[email protected]
US
No
Jay Lyle
[email protected]
US
Margaret Dittloff
[email protected]
US
No
Walter Suarez
[email protected]
US
No
Peter Hendler
[email protected]
US
No
Ray Simkus
[email protected]
CA
No
Audrey Dickerson
[email protected]
US
No
Ian McNicoll
[email protected]
UK
Yes
Elayne Ayres
[email protected]
US
Yes
Lloyd Mackenzie
[email protected]
CA
Yes
Danny Probst
[email protected]
US
Yes
Notes
Yes
Yes
LM&A Consulting Ltd.
Page 3
Participants- Meetg of 2011-02-09
Name
email
Count
ry
Yes
No
André Boudreau
[email protected]
CA
Yes
Laura Heermann Langford
[email protected]
US
Yes
Stephen Chu
[email protected]
AU
No
Peter MacIsaac
[email protected]
AU
No
David Rowed
[email protected]
AU
No
Adel Ghlamallah
[email protected]
CA
William Goossen
[email protected]
NL
No
Anneke Goossen
[email protected]
NL
No
Ian Townsend
[email protected]
UK
No
Charlie Bishop
[email protected]
UK
No
Rosemary Kennedy
[email protected]
u
US
Jay Lyle
[email protected]
US
Margaret Dittloff
[email protected]
US
Yes
Walter Suarez
[email protected]
US
Yes
Peter Hendler
[email protected]
US
yes
Ray Simkus
[email protected]
CA
Yes
Audrey Dickerson
[email protected]
US
Yes
Ian McNicoll
[email protected]
UK
Yes
Notes
Yes
Yes
No
Page 4
Last updated: 2011-02-16
Participants- Profile notes - 1
Name
Count
ry
Organization
Notes
André Boudreau
CA
Boroan Inc. (Consulting)
Chair, Individual Care SCWG No. 2 (pan Canadian Standards
Collaborative Working Group); project manager – standards
projects; HL7 EHR and PHR WG
Laura Heermann
Langford
US
Intermountain
Healthcare
RN PhD,: Nursing Informatics; Emergency Informatics Association,
American Medical Informatics Association; IHE
Stephen Chu
AU
NEHTA-National eHealth
Transition Authority
RN, MD, Clinical Informatics; Clinical lead and Lead Clinical
Information Architecture; co-chair HL7 Patient care WG; vice-chair
HL7 NZ
Peter MacIsaac
AU
HP Enterprise Services
MD; Clinical Informatics Consultant; IHE Australia; Medical
Practitioner - General Practice
David Rowed
AU
Family medicine practice
MD;
Adel Ghlamallah
CA
Canada Health Infoway
SME at Infoway (shared health record); past architect on EMR
projects
William Goossen
NL
Results 4 Care B.V
RN, PhD; -chair HL7 Patient Care WG at HL7; Detailed Clinical
Models ISO TC 215 WG1 and HL7 ; nursing practicioner
Anneke Goossen
NL
Results 4 Care B.V
RN; Consultant; Co-Chair Technical Committee EHR at HL7
Netherlands; Member at IMIA NI; Member of the Patient Care
Working Group at HL7 International
Ian Townend
UK
NHS Connecting for
Health
US
NIH National Institutes
of Health
Elaine Ayres
Health Informatics; Senior Interoperability Developer, Data
Standards and Products; HL7 Patient Care Co-Chair
MS, RD; Deputy Chief, Laboratory for Informatics Development, NIH
Clinical Center ; Project manager for BTRIS (Biomedical
Translational Research Information System), a Clinical Research
Data Repository
Page 5
Last updated: 2011-02-16
Participants- Profile notes - 2
Name
Charlie Bishop
Count
ry
Organization
Notes
UK
iSOFT
Product Manager - Information & Integration ; HL7 Patient care WG
Rosemary Kennedy
US
Thomas Jefferson
University School of
Nursing
RN; Informatics; Associate Professor; HL7 EHR WG; HL7 Patient
care WG; terminology engine for Plan of care;
Jay Lyle
US
JP Systems
Informatics Consultant; Business Consultant & Sr. Project Manager
Margaret Dittloff
US
The CBORD Group, Inc.
RD (Registered Dietitian); Product Manager, Nutrition Service Suite;
HL7 DAM project for diet/nutrition orders; American Dietetic
Association
Walter Suarez
US
Kaiser Permanente
MD, MPH; Director of Health IT Strategy; national priority for
transition of care; WEDI- Workgroup for Electronic Data Interchange
Peter Hendler
US
Kaiser Permanente
MD; informatics; lead in KP convergent terminology; SNOMED CT
Ray Simkus
CA
Brookswood Family
Practice
MD; Family medicine; EMR user; active meber various standards
WG in Canada; on IHTSDO Contents Committee
Audrey Dickerson
US
HIMSS
RN, MS; Standards Initiatives at HIMSS; ISO/TC 215 Health
Informatics, Secretary; US TAG for ISO/TC 215 Health Informatics,
Administrator; Co-Chair of Nursing Sub-committee to IHE-Patient
Care Coordination Domain.
Ian McNicoll
UK
Ocean Informatics
Health informatics specialist; Formal general medical practitioner;
OpenEHR; Slovakia Pediatrics EMR; Sweden distributed care
approach
Danny Probst
US
University of Utah
Nursing Informatics MS Student
Page 6
Last updated: 2011-02-09
First Meeting(3-4) Objectives
•
•
•
•
•
Agree on where we are and where we want to go
Agree on the approach to get there
Identify what is available and what is missing
Identify tasks and develop realistic work plan
Agree on roles and mechanics
• Note: these objectives will be replaced by another
set as a result of the above
Page 7
Last updated: 2011-02-16
Contents
•
•
•
•
•
•
•
Care plan status update
Where we want to be
Methodology: how to get theer
What has been done
Gaps
Team and roles
Conclusion
 Next steps
 Next meetings
Page 8
Last updated: 2011-02-09
CARE PLAN STATUS UPDATE
Page 9
Last updated: 2011-02-16
Where we are
• We have a Care Plan DSTU
• We have an approved March 2010 Project Scope Statement
 Questions were raised and discussed regarding development
processes, artefacts to be created and the types of ballots
• Use cases and storyboards have been collected
 Some are on the wiki and HL7 PC WG page
o Danny Probst is working with Laura to complete this inventory
 Not standardized, not reviewed
 More would be available
o Canada (Blueprint 2015)
• We have details on the methodology (see later)
• Ask William Goossen for more details (add on next page)
Page 10
Where we are (William?)
Page 11
Last updated: 2011-02-09
WHERE WE WANT TO BE (TARGET)
Page 12
Last updated: 2011-02-09
Objectives of this phase
• Get more familiar with HL7 chain of deliverables (HDF)
• Consolidate and clarify business and clinical requirements
 Under what circumstances is it necessary to communicate a care
plan?
 Include clinical guidelines
 Distributed care planning as in Sweden: meta data needed
 For what business purpose are organizations paying their
employees to volunteer and develop this standard?
• Assemble use cases and analyze
• ?Develop DAM
• Scope: decide whether the DAM scope should be restricted to
the care plan or should reverse-engineer the entire Care
Provision DIM
• Update objectives once we have a better handle on our
methods
Page 13
What scope?
• Care plan vs all of patient care?
Page 14
Last updated: 2011-02-09
Notes from Jay Lile – 2011-02-03
1. INFORMATION: The DAM should inform a constrained model (DIM/DMIM/RMIM), which is
then used as the basis for specifications (CDA, message, etc.). If we build a DAM, we'll
presumably use it to update the Care Provision DIM. The updated DIM should be in the
list of balloted deliverables. (This is much clearer in PSS 4d, but the sections should be
in harmony.)
2. SCOPE ISSUE: We will also need to determine whether the DAM scope should be
restricted to the care plan or should reverse-engineer the entire Care Provision DIM.
3. PSS (Project Scope Statement) UPDATE: The Scope section (4a) discusses semantic
scope, but it does not lay out the scope of work. I'd suggest that the text currently in 2a
be removed from 2a, expanded, and added to 4a.
4. GUIDELINE: The term "DSTU" is being used to refer to deliverables. I find that
confusing: DSTU is a status, not an artifact. It would be clearer to me if artifacts were
referred to as messages, cda documents, DAMs, and DIMs, and ballot status were used
to modify those artifacts. E.g., "the purpose of this project is to develop a Care Plan CDA
document, with all necessary antecedent artifacts [list them], and to ballot this
document as DSTU."
5. DELIVERABLES: Modeling the information space will almost certainly be useful, but I'm
still in the dark about the use cases. Under what circumstances is it necessary to
communicate a care plan? For what business purpose are organizations paying their
employees to volunteer and develop this standard?
6. PSS UPDATE: External collaboration (6) could use more detail. That would also make it
less necessary to mention this slightly distracting information in previous sections.
Page 15
Last updated: 2011-02-??
What is a DAM?
• The rules around what constitutes a valid DAM, how to put
boundaries around them, or even what the tools are slim to
none. What that means is you can largely do whatever you want - at
least for now.
Page 16
Last updated: 2011-02-16
Lloyd Mackenzie: Observations on DAMs -1
• Presently, a DAM is not something well defined in HL7. It is not a
single artefact but a variable collection of artefacts: functional
requirements, use cases, behavioural models, activity diagrams,
interaction diagrams, etc.
• There are 3 levels of design: conceptual, logical and implementable.
The DAM is at the conceptual level
• For the conceptual level:




Capturing requirements is key
Requirements must be intuitive to the user community and verifiable
This level is more detailed that the logical level
It must be well bounded because conceptual models tend to be large
• The conceptual information model
 The challenge is arriving at a language and set of well defined concepts
accepted by the broad community of stakeholders/ clinicians
 Definitions are critical: include usage notes, examples and aliases
 Note: ISO Continuity of care concepts (NWIP being balloted to merge the 2
parts) could be one key input to speed things up
 The model must be mapped and validated against the RIM to ensure
completeness
Page 17
Last updated: 2011-02-16
Lloyd Mackenzie: Observations on DAMs -2
• We need to decide which artefacts we will produce
 HL7 does not have a formal set of tools nor predetermined publication
format
 We need to speak to the Publications WG early in the process to ensure
that what is prepared can be handled for ballot
• For the models, 2 major options
 Concept maps (e.g. mind maps): easy for clinicians to understand, less
technical looking
 UML diagram: they are more precise, with cardinalities; can be ‘scary’ for
non technical folks; could come after the concept maps
• Datatype: do we want to specify? If so, which ones? R2? They are
very technical and could be added at a later point.
• Key: decide on core objective: capture requirements and validate
with user community
 Find ways to make this easier
Page 18
Last updated: 2011-02-16
Discussion with Lloyd
• References to look at
 Wiki on Conceptual Information model: this is not firm, has not been
reviewed nor accepted
o Link??




HDF
SAIF
Other sources
Our imagination
• We have to make our own choices to arrive at our objectives. HL7
has not resolved the techniques and tools
• Group decision: start with a concept map, get acceptance by
clinician, then move to class diagrams/UML
• In Sydney, an updated presentation was given on DAM guidelines:
Stephen will send
• There are free mind mapping tools available: Stephen will send info
on one
• The experience gained in this initiative should be communicated to
HL7 to help clarify the methodology and the tools
Page 19
Deliverables (to be updated after a few
weeks of travel…)
Last updated: 2011-02-09
• NB: Care Plan wiki to be used for all documents
 Laura and André to manage?
• See HDF Domain Analysis- later
• Project Scope Statement
 Eventually…
• DAM
 storyboard, use cases, structural models, dynamic models
• Care Plan CDA?
• Care Plan v3 message?
Page 20
Last updated: 2011-02-09
METHODOLOGY: HOW TO GET THERE
Page 21
Last updated: 2011-02-16
Approach to Follow
• We will follow the Domain Analysis Process (DAP) of
the HL7 development Framework (HDF)
 See overview diagram on the next page
• We need to familiarize ourselves with the approach
 See Appendix 1 for a summary of the HDF DAP process and
techniques
 CIC DAM Development Guide HL7 PC 20110104Draft.pptx
 Format for use cases, storyboards, activity diagrams and
interaction diagrams - HL7Wiki.mht
• Examples
 EMS Domain Analysis Model VOORBEELD.pdf
Page 22
Last updated: 2011-02-09
HDF- Domain Analysis Overview
act 3: Domain Analysis Ov erv iew
Business
Requirements
Source: HDF_1.5.doc, page 37
Project
Approved
Analyze Use
Cases
Analyze Business
Context
(from 3.4.2 Use Case Analysis)
«outcome»
(from 3.4.1 Business Context Analysis)
«outcome»
Use Case Analysis
Story board
(from 3.7 Artifacts)
(from 3.7 Artifacts)
Analyze Process Flow
(from 3.4.3 Process Analysis)
Process Flow
(from 3.7 Artifacts)
Glossary
Analyze Information Exchanged
(from 3.7 Artifacts)
(from 3.4.4 Information Analysis)
Information Model (Analysis)
(from 3.7 Artifacts)
Analyze Business Rules
«optional»
Business Rules Description
(from 3.4.5 Business Rules Analysis)
(from 3.7 Artifacts)
Business Trigger Analysis
(from 3.7 Artifacts)
Publish DAM
DAM Approv al
Page 23
Last updated: 2011-02-09
WHAT HAS BEEN DONE
Page 24
Last updated: 2011-02-09
What do we have
•
•
•
•
Approved PSS that needs revision when we are ready
Use cases and storyboards (next page)
Glossaries: HL7, EHR WG
CEN Continuity of care P1 and P2
 CEN docs are published
 Information model and processes and workflow
•
•
•
•
Care plan DSTU of 2007
IHE models of the PPOC (Patient Plan of Care)
To be updated with a good inventory (see next page)
NB: we need all the assets in one location (or at least links to
other locations would be found in that spot)
Page 25
Last updated: 2011-02-09
Use Cases and Storyboards on Hand
•
•
•
•
•
•
Care Plan Storyboards - HL7Wiki.mht
Care Plan Use cases - HL7Wiki.mht
CarePlanPneumoniaStoryboard.doc
Goossenetal2004Jamia-nursingprocessHL7-186.pdf
Care coordination usecases v-9 IHE Australia.doc
CarePlanTopicUseCasesDiabetesCare22-112010.doc
• IHE-PCC_ProfileProposal_Chronic_Care_Coordination-1-AU.doc
• To be updated
Page 26
Last updated: 2011-02-09
GAPS AND WORKPLAN
Page 27
Last updated: 2011-02-09
Gaps
Page 28
Last updated: 2011-02-09
Workplan
• High level here, comprehensive on Excel
• There was a work plan
 PC CarePlanTopic Planning & Controllist_v02.xls
Page 29
Last updated: 2011-02-09
TEAM AND ROLES
Page 30
Last updated: 2011-02-09
Team and Roles (WIP)
Name
email
Role
André Boudreau
CA
[email protected]
CP Co-Lead
Laura Heermann
Langford
US
[email protected]
CP Co-Lead
Stephen Chu
AU
Peter MacIsaac
AU
David Rowed
AU
Adel Ghlamallah
CA
William Goossen
NL
Anneke Goossen
NL
Ian Townsend
UK
Charlie Bishop
UK
Rosemary Kennedy
US
Jay Lyle
US
Notes
WG Co-Chair
WG Co-Chair, DCM
ETC. To be augmented
Page 31
Last updated: 2011-02-09
Team and Roles- Notes
• Resource issue - the need to fill the roles of HL7 modeling and
vocab facilitators to progress the works
Page 32
CONCLUSION
Page 33
Last updated: 2011-02-09
Concluding notes
• Approach is OK
• Have 1 or 2 or 3 more calls to sort ourselves out
• Weekly calls at 17h00 ET
Page 34
Issues/Questions as of 2011-02-16
No.
Date
Issue Name
Comments
Owner
Status
1
2
3
4
Page 35
Action Items as of 2011-02-16
No.
Action Items
By Whom
For
When
Status
1.
Clarify procedure and obtain rights for André/Laura to update CP wiki
William?
Active: Procedure obtained
2.
Do an inventory of use cases and storyboard on hand
Laura
(Danny)
Active: Underway
3.
Ask William for an update (add in a diff colour to the appropriate pages)
André
Outstanding - Request
made
4
Prepare summary of the steps from HDF to produce the DAM
André
Done. See Appendix 1
5
Obtain and share the published version of the CEN Continuity of care P1 and P2
Audrey
Outstanding
6
Provide copy of the DAM presentation in Sydney and the name of a free mind
mapping tool
Stephen
Done. Sent to list.
Page 36
APPENDIX 1- DOMAIN ANALYSIS PROCESS (DAP) IN
THE HL7 DEVELOPMENT FRAMEWORK (HDF)
Source: HDF 1.5 R1 (Nov. 2009), Section 3- Domain Analysis
Process (DAP): Analysis and Requirements Documentation
Page 37
HDF DAP Appendix Contents
• Overview
• Process





Business context analysis
Use case analysis
Process analysis
Information analysis
Business rules analysis
• Quality criteria
• Tools
• Artefacts
Page 38
Overview- 1
• Domain Analysis produces a set of artifacts that clearly describe the
healthcare business in a given domain in terms familiar to the people
who work in that business area. This set of artifacts comprises a
Domain Analysis Model (DAM). HL7 workgroups use these artifacts to
develop V3 standard specifications. Each artifact in the DAM must be
unambiguously stated in a way that can be well understood both by
the domain experts and by the HL7 project members who are
responsible for developing the specification.
• This section presents a set of internally consistent processes and
techniques for analyzing and documenting interoperability
requirements. It allows domain experts to document requirements
explicitly in a manner consistent with HL7 design. These processes
make extensive use of the UML 2.1 standard notation and tooling
(see sections 3.6 and 3.7). The process encourages project teams to
focus on the underlying healthcare information and process
requirements before designing a standard. While the focus of this
chapter is to identify interoperability requirements for standard
development, this process could be used to analyze requirements for
other purposes or projects.
Page 39
Overview- 2
• Requirement/Domain Analysis is a task typically performed by
domain experts and business analysts who represent the users and
understand their system interoperability needs. The problem space
for HL7 is defined by the interoperability requirements of
stakeholders in a given domain of healthcare delivery or
administration. This includes all sharing of information among
healthcare stakeholders that may be required for the collection,
aggregation, reporting, and other analysis of clinical, administrative,
and financial data information that pertains to the business.
• A DAM defines what needs to be done, not how to do it. It is
important to separate the description of requirements from the
design of the solution. Prematurely including technical and
implementation details will compromise the clarity of the original
problem and will result in standards that fall short of the business
needs. The DAM is used to create standard specifications by
harmonizing it with HL7 references including the Reference
Information Model (RIM), structural vocabulary, and application roles.
Page 40
HDF- Domain Analysis Overview
act 3: Domain Analysis Ov erv iew
Business
Requirements
Project
Approved
Analyze Use
Cases
Analyze Business
Context
(from 3.4.2 Use Case Analysis)
«outcome»
(from 3.4.1 Business Context Analysis)
«outcome»
Use Case Analysis
Story board
(from 3.7 Artifacts)
(from 3.7 Artifacts)
Analyze Process Flow
(from 3.4.3 Process Analysis)
Process Flow
(from 3.7 Artifacts)
Glossary
Analyze Information Exchanged
(from 3.7 Artifacts)
(from 3.4.4 Information Analysis)
Information Model (Analysis)
(from 3.7 Artifacts)
Analyze Business Rules
«optional»
Business Rules Description
(from 3.4.5 Business Rules Analysis)
(from 3.7 Artifacts)
Business Trigger Analysis
(from 3.7 Artifacts)
Publish DAM
Source: HDF_1.5.doc, page 37
DAM Approv al
Page 41
3.4.1 Business Context Analysis
• The first sub-process in the Requirements Documentation
process analyzes specific issues or requirements in the context
of the healthcare business process that is to be improved
either by developing new software or through HL7-based
interoperability.
• This is accomplished using one or more storyboards. A
storyboard is a narrative that describes a representative
scenario that illustrates the problem or requirement as well as
identifying the interchange of information and the various
actors involved.
• The purpose of this sub-process is to capture the domain
experts’ knowledge in a simple fashion and to document the
business context for message exchange. The analysis of the
business context is intended to identify a typical scenario (or
storyboard) that describes the process intended for
automation using the standard developed by the project.
Page 42
3.4.1 How to document the business
context
Page 43
3.4.2 Use Case Analysis - 1
• Use Case Analysis is used to identify the integration scenarios a project or
artifact is intended to support.
• The Use Case Model formally identifies the actors and use cases illustrated in
the storyboards and associates the actors with the use cases they participate
in. It enables the project or committee to clearly identify the functional areas
the system will cover and the actors involved. A Use Case Model may consist
of multiple use cases and multiple actors.



Each use case provides one or more scenarios that convey how the system should
interact with the end user or another system to achieve a specific business goal. Use
cases typically avoid technical jargon, preferring instead the language of the end user
or domain expert.
Each use case focuses on describing how to achieve a single business goal or task.
Actors are parties outside the system that interact with the system. An actor can be a
class of users, roles users can play, or other systems.
Use cases treat the system as a "black box" and interactions with the system,
including system responses, are perceived from outside the system. This policy is
deliberate because it simplifies the description of requirements and avoids the trap of
making assumptions about how the functionality will be implemented.
Page 44
3.4.2 Use Case Analysis - 2
• A use case identifies:





Actors participating in the use case
Pre-conditions
Flow of events
Post-conditions
Derived events/interactions
• Activity, Sequence, and/or State diagrams can be used to
further elaborate the use case analysis.
Page 45
Analyze Use Cases
The purpose of the following diagram
is to describe the process used to
identify the actors and use cases in a
formalized structure that enables
Domain Experts and Business
Requirements Analysts to identify the
functional interoperability scenarios.
act 3.4.2: Analyze Use Cases
Analyst :Business Analyst
Business Requirements
(from 3.4 Process and Tasks)
Document Actors' Actions: Analyze
the storyboards to identify the
systems, business actors, and
functions/actions performed.
Describe interoperability use
cases: Describe the conditions under
which information is exchanged and
the responsibilities of each actor based
on information received.
Facilitator :HL7 Modeling Facilitator
Glossary
(from 3.7 Artifacts)
Document Actors'
Actions
Describe interoperability
use cases
Document use cases
and actors
«outcome»
Use Case Analysis
(from 3.7 Artifacts)
Page 46
Additional Guidance
• Consider writing use case text only for those cases whose
steps include interoperability to keep the analysis manageable.
• Create the use case model with respect to the system that
initiates the information exchange. The system that receives
the message of interest is a secondary actor in the use case.
• After writing the use case text, include one or more scenarios.
• Create scenarios for the use case messaging success and
failure conditions if there are any and they affect the contents
of the message. A use case scenario illustrates a single
instance of the flow through a use case. It typically does not
include any options. You may rely on additional scenario to
describe various options.
Page 47
3.4.3 Process Analysis
• The process flow shows the information exchange necessary
for automation of a healthcare business process. In UML,
Activity Diagrams are used to visualize the activities and flow
of a healthcare business process as described by use cases.
Each Activity Diagram may be represented using a Process
Flow - see section "3.7 Artifacts, Process Flow" for details.
• The purpose of this sub-process is to document how a project
or committee may capture the behavior described in the
business process in a structured notation (UML) using UML
tools.
Page 48
Analyze Process Flow
Refine the steps in the use
case model: Clarify and
expand the storyboard into
an Activity Diagram. The
Activity Diagram will visualize
the activities and flow of a
healthcare business process.
The facilitator will use UML to
document these process
steps.
Document Information
Exchange: The process flow
is broken into steps and then
the message exchange is
clearly illustrated. Special
care will be paid to message
processing rules and to
identifying the business
triggers.
act 3.4.3: Capture Process Flow
Facilitator :HL7 Modeling Facilitator
Analyst :Business Analyst
Use Case Analysis
(from 3.7 Artifacts)
Refine the steps in the
use case model
Document Information
Exchange
Review
Process Flow
(from 3.7 Artifacts)
Review may require several
iterations
Page 49
3.4.4 Information Analysis
• One of the most important aspects of requirements analysis is
the development of a clear understanding of the business
objects of interest, their associations, and their attributes. The
purpose of this sub-process is to document the information
shared between systems in order to support healthcare
business processes. UML class diagrams are used to describe
the information required to appear in messages.
Documentation of the structure of a particular business
process is done using a combination of an information model,
represented as a UML Class Diagram, and a carefully written
glossary of the terms used by domain experts to define the
static elements within that process.
Page 50
Analyze Information Exchanged
The information model and its
associated diagrams document
the static syntactic and
semantic relationships of
importance in the healthcare
business process including the
responsible parties/entities
and the various data
elements/structures required
by the process. The semantic
meaning of each item and
attribute in the information
model is described in the
model documentation. The
following diagram describes
the steps required to develop
the information analysis
artifacts.
act 3.4.4: Analyze Information Exchanged
Analyst :Business Analyst
Facilitator :HL7 Modeling Facilitator
Use Case
Analysis
Process Flow
Glossary
(from 3.7 Artifacts)
(from 3.7 Artifacts)
(from 3.7 Artifacts)
SME :Domain Expert
Analyze Information Shared
[message
content
incomplete]
Analyze value sets
[value sets
incomplete]
Information Model (Analysis)
(from 3.7 Artifacts)
Review Model
See next page
Page 51
Analyze Information Exchanged
• Analyze Information Shared
 Document and specify the information payloads of interest:
o For each exchange of data identified in the activity diagram, determine
the data elements required.
o For each data element include a complete definition that is not selfreferential and includes examples, where appropriate.
o Apply a consistent style guide. This includes naming conventions for
class, attribute and association names (e.g. Upper Camel Case. Lower
Camel Case, etc).
• Analyze value sets
 The local value sets, code systems, and code sets are identified
and documented as enumerations in the UML model (each literal
corresponding to a code). If any external code sets are used, they
will be named explicitly in the information model. If any external
code systems are used, they will be named explicitly in the
information model. Each new vocabulary term must use
”definition” syntax that is not self-referential with examples, etc.
Page 52
3.4.5 Business Rules Analysis
• The main purpose of this process is to describe how a
committee or project should document additional business
rules that are important in creating the message specifications
such as business triggers for messages. This structure is
added to the Activity Diagram using the "object/instance"
iconography (in the case of HL7 Specifications, most objects
that are exchanged are data objects that have no inherent
behavior). An analysis of the business rules produces
important information to describe any events that trigger the
exchange of information.
Page 53
Describe the business rules and triggers
Analyze state transitions for
business objects: Analyze the
data exchange requirements that
appear as Data Objects in the
Activity Diagrams. Document the
life cycle of each of these data
objects in UML State Diagrams.
act 3.4.5: Analyze Business Rules
Analyst :Business Analyst
Facilitator :HL7 Modeling Facilitator
SME :Domain Expert
Process Flow
(from 3.7 Artifacts)
Analyze other business rules:
Analyze the Story Boards and
Activity Diagrams to determine
Business Rules and conditions that
are not adequately captured in the
Domain Analysis Model, Domain
Glossary and State Chart. A
complete DAM will include a
thorough analysis of business rules
governing the processing and
exchanging information in order to
meet interoperability
requirements.
Information Model (Analysis)
(from 3.7 Artifacts)
Analyze state transitions for business objects
Use Case Analysis
(from 3.7 Artifacts)
Business Trigger Analysis
(from 3.7 Artifacts)
Analyze other business rules
«optional»
Business Rules Description
(from 3.7 Artifacts)
Page 54
Describe the business rules and triggers
• Additional guidance
 Given that the information model, class and attribute
glossary, and state charts may overlap when documenting
the business rules, there is no need to document those
business rules in the rules analysis.
 As a guiding principle, analysis should focus on those
business rules that will be important to the interoperability
as specified by the business use cases.
 Business rules may be written in an informal style or in a
consistent formalized style. It is advisable to begin
capturing business rules in an informal style. A more formal
style can be created later, if needed.
Page 55
3.5 Quality Criteria (requirement specifications)
•
•
•
•
•
•
•
•
Requirements specifications must be complete, correct, unambiguous, deterministic, testable, verifiable,
traceable, and internally consistent.
If complete, a requirements specification must specify all information needed to develop the static and
dynamic logical and implementation models. It should not include unnecessary information. It must
provide the detail necessary to develop the HL7 model specification. For example, a requirements
specification “send prescription data to the pharmacy” is not complete. It does not address questions
such as “What is the prescription data?” or “What is the pharmacy supposed to do with it?”
If correct, the requirements specification must correctly specify the conditions and limitations that will be
encountered in building the model. Building on the earlier pharmacy example, how should the model
behave if the prescribed medication is not available in the pharmacy?
An unambiguous requirements specification leaves no room for doubt. Data that is exchanged or stored
needs to be clearly defined. Message elements that are not well defined inevitably lead to
interoperability issues.
A testable requirements specification is one where each requirement can be examined once the HL7
model is complete to determine if the model does indeed fulfill the requirement. As such, requirements
need to be specified in an objective fashion. Using UML to represent the requirements for the static and
dynamic models helps eliminate issues like these.
A requirements specification is consistent as one examines the transitions from lesser to greater detail.
A traceable requirement is one that can be traced backwards and forward through the requirements
documentation process.
Requirements must be internally consistent. One requirement must not conflict with another.
Page 56
3.6 Tools
• A UML 2.1 tool may be used to analyze the integration
requirements that are intended to be met by standard
specifications and supports the creation of DAM artifacts
outlined in section 3.7. HL7 recommends the use of Eclipsebased UML 2.1 tools that can be extended easily using opensource plug-ins and features.
Page 57
3.7 Artifacts
class 3.7 DAM Artifacts
Domain Analysis Model (DAM)
Use Case Analysis
Process Flow
Story board
Business Trigger Analysis
Information Model (Analysis)
«optional»
Business Rules Description
Glossary
Page 58
Domain Analysis Model (DAM)
• A Domain Analysis Model is an analysis model that describes
business processes, use cases, process flows, business
triggers, and the information exchanged that are derived from
a project's requirements. A sample domain analysis model is
available in Annex A.
• A DAM is equivalent to a Requirements Analysis Specification
but instead introduces a consistent notation (UML 2) and style
in place of narrative analysis information. Domain analysis is a
well-established discipline in software development that is
intended to improve the way in which requirements are related
to SMEs, analysts, and integration solution implementers. The
artifacts described here adapt the best-practices established in
software development to the development of healthcare
standards. Having well-documented and thoroughly analyzed
requirements of standard design specifications will better
prepare HL7 work groups to respond to ballot comments and
questions.
Page 59
Domain Analysis References
• Carnegie-Mellon University has developed its own analysis
methodology known as "Feature-Oriented Domain Analysis" that has
been applied widely in public/federal and private industry projects.
Please refer to the following for more information:
• Kayo C. Kiang, Shalom G. Cohen, James A. Novak, William E. Hess,
and A. Spencer Peterson, "Feature Oriented Domain Analysis (FODA)
Feasibility Study", CMU/SEI-90-TR-21, Software Engineering
Institute, Pittsburgh, PA, November, 1990



http://www.sei.cmu.edu/domain-engineering/domain_anal.html
http://www.sei.cmu.edu/str/descriptions/foda.html
http://www.sei.cmu.edu/str/descriptions/deda.html
• Though based on generic domain analysis, the focus of the HDFbased methodology is in specifying how we in healthcare
interoperability use DAMs for standard development. It is important
to mention that a DAM contains not only an information model but
also a comprehensive analysis model which includes business
processes and system interactions. The behavioral/dynamic aspect of
a DAM is often overlooked by HL7 standard developers.
Page 60
Use Case Analysis Model
• The Use Case Analysis describes typical scenarios of end-users interacting
with systems for the purposes of sharing or looking up information. In HL7,
the Use Case Analysis is a documented as a UML model or package in the DAM
that describes a interoperability requirements in terms of use cases. It
consists of all the actors of the systems involved in interoperability and all the
various use cases by which the actor interact with the system, thereby
describing the functional and integration behavior of the systems involved.
• Use case models specify actors and use cases:


1. Actors: An actor is a person who will use the system we are designing. A bank
customer interacting with the software of an automated teller machine is an actor. An
astronomer inputting the coordinates of a star to a telescope aiming program is an
actor. A bookstore clerk checking the computer to see if a particular book is available
is an actor. Usually an actor initiates some operation, although sometimes the actor
may act in other ways, such as receiving information or assisting in an operation.
In a large project, just identifying all the actors may be difficult. The designer needs
to look for people or other systems that:
o
o
o

Provide information to the system
Need information from the system
Assist other actors
2. Use Cases: A use case is a specific task, usually initiated by an actor. It describes
a single goal the actor wants to attain. Examples are the applying for driver's license,
renewing a driver's license, etc. A detailed example of use case analysis is provided in
Annex A.
Page 61
Storyboard
• A storyboard is a narrative description of a series of steps involving some exchange of
information between different participants to achieve the objectives of a healthcare
business process. The list of steps can be in generalized, abstract terms, or in the form of
a real-world example. A storyboard illustrates the basic path, simple path, alternate, or
error path of information and its content is comprised primarily from guidance by the
domain experts.





Storyboards should be written using business terminology to illustrate the context for the message
exchange, functional model, etc.
The content of the initial storyboards should be representative of normal business processes. Avoid
exception cases. Attempting to document all exception cases in a business process can be an
exhaustive task that diverts focus from the typical case, particularly at this early stage of the
requirements process.
A storyboard may be imprecise or incomplete in its initial draft. It should be revised over time if
changes/updates are deemed important. It typically has no branching or decision points. The
information in a storyboard will typically be made more precise when the corresponding Activity
Diagram is created.
The storyboard may include examples (e.g. names of people, organizations, systems, and data
values) as appropriate. This helps make storyboards illustrative of the real work and also to make
clear that items of interest may be of different types than assumed (e.g. that a patient in some
cases may be an animal, that a guarantor may be an organization, etc).
Avoid the use of acronyms, abbreviations, etc., because the intended audience is a diverse group,
some of whom would likely be confused. If these constructs are deemed important for the intended
audience, they can be included in parentheses after the term. For example, Department of Motor
Vehicles (DM).
Page 62
Glossary of Business Terms -1
• The Glossary focuses on the business objects of interest and their
attributes. Some of the concepts in the glossary may also appear as
classes or attributes in the information model:
 The Glossary uses business-specific names and references with
unambiguous definitions provided by the SMEs and analysts.
 Element definitions must be understood by the SMEs and any end users.
 To jump-start the modeling process, it's sometimes helpful to think of the
events, the relevant parties (persons and organization), places, and items
that participate or are used in those events, and how they participate in
those events. Consider as well any "catalogs" of events and items.
 The objects that appear in the activity diagram are a primary source for
this analysis artifact.
 Some data objects will have been identified in the business requirements.
Page 63
Glossary of Business Terms -2
• It is generally most beneficial to go for breadth first and depth later.
Therefore, capture the classes and only enough attributes to distinguish them
before attempting to identify all the attributes. Similarly, capture only the
relationships between classes before attempting to document their cardinality
(“can there be more than one?”) and optionality (“must there be one?”).





Make the model just "good enough". Avoid the temptation to perfect it or make it
exhaustive. Don't get attached to this model. As the iterative process progresses
you'll learn more information and later models will improve.
While most models benefit from the use of conventions, do not invent conventions to
the detriment of creating the model. Annex F provides naming conventions to start
with.
Whenever possible, use the features of the UML modeling tool to create the Domain
Glossary.
UML modeling tools can generate a document of the class and attribute definitions to
auto-generate the glossary publication.
Review definitions from glossaries of other standards development organizations,
industry consortium, dictionaries, etc. whenever feasible. HL7 encourages
collaboration with these third-party organizations and respects their intellectual
property. Always reference the original source in the definition.
Page 64
Information Model (Analysis)
• The UML-based information model contains classes,
attributes, associations, and packages required to describe the
information shared by systems in order to support the business
requirements for a standard specification. Local value sets may be
expressed as classes called enumerations and assigned to coded
attributes.
• The information model is not the actual specification of payload
structures as it does not include the order of the data items in the
message, the exact formats of the individual data items, the exact
location of the data items within the message, and it might not
include the exact data types of the data items in the message.
Rather, it’s an analysis of the information required to support the
underlying requirements expressed in a way in which SMEs can relate
to the information, semantics, and structure.
• This model is not an HL7 static/information model but instead an
element of the DAM. It describes the information exchanged to
support a project's requirements (for a project intended to produce
interoperability standards).
Page 65
Business Trigger Analysis
• This analysis artifact documents the allowed states and transitions
that correspond to message triggers. The "state change" triggers are
similar to trigger events defined in HL7 specifications, but they relate
to events in the "real world". While HL7 has pre-defined a set of
states and transitions, the targeted business area may require
different levels of granularity.
• These states and transitions will eventually be mapped or related to
HL7 reference states and transitions for each type of Reference
Information Model (RIM) class (e.g. Act, Managed Participation, Role,
and Entity).
• When analyzing the state events for an object, candidate states in a
state chart diagram for an event could be active, completed,
suspended, or terminated.
• Typically, the activities for DAM creation and creation of a
comprehensive Activity Diagram "feed" each other. They may be
performed in parallel, by switching back and forth between one and
the other, or some other combination.
Page 66
Process Flow
• The process flow represents a dynamic view of end-user and system interactions and is
often the best way to represent the interactions between systems, derive the application
roles, and trigger events. Process flows rely on UML Activity and/or Sequence Diagrams
to represent the sequence of user-to-system and system-to-system actions required for
specific business processes.
• An Activity Diagram identifies a sequence of steps and the information that is
transferred from one participating role/actor to another. Sometimes called a "Swim-Lane
Diagram", the diagram represents the flow of control and helps identify when information
is required to be transmitted to achieve the objectives of the storyboard. These diagrams
use UML 2.x notation to represent actions, activities, decisions, control, and information
flows between users and systems. An activity diagram is also a variation of state machine
in which the states represent the performance of actions or sub-activities, and the
transitions are triggered by the completion of the actions or sub-activities. Therefore, it
represents the state machine of a procedure itself.
• A Sequence Diagram is used to represent the flow of messages, events and actions
between the systems or components of a system. Time is represented in the vertical
direction while the sequence of interactions of the header elements are displayed
horizontally. Sequence diagrams are used primarily to document and validate the
architecture, interfaces, and logic of various system scenarios by describing their action
sequences. Sequence diagrams provide a dynamic view of the system behavior which can
be difficult to extract from static diagrams or specifications. Although sequence diagrams
are typically used to describe object-oriented software systems, they are also extremely
useful as system architecture engineering tools, as process flow diagrams in business
process engineering, and as message sequence charts and call flows for system design
and analysis.
Page 67
Business Rules Description
• Business rules may be described using a variety of dynamic views
(business process diagrams, activity diagrams), narrative text, or
constraint language statements (e.g. OCL) based on the DAM. These
business rules may be used to apply additional constraints to the
information exchanged or processing rules.
 The bullet items below describe sample business rules using natural
language:
 At any point in time, a person can hold a driver’s license (active or
suspended) in only one state.
 In order to obtain or renew a driver’s license, a person must have no
moving motor vehicle violations in the past three years.
 In order to obtain or renew a driver’s license, a person must have no
health issues that would adversely affect their ability to operate a motor
vehicle.
 The Department of Motor Vehicles accepts the following payment methods
- cash, check with acceptable picture ID, or MasterCard/Visa credit/debit
cards.
Page 68