impact of information technology on the quality of health services

POLITEHNICA University of BucharestPOLITEHNICA University of BucharestFaculty of Control and ComputersFaculty of Control and Computers

Impact of Information TechnologyImpact of Information Technology on the Quality of Health Services

RADU DOBRESCU


A draft vision for eHealthOverall goal to improve health and quality of health-related

information

Integrated eHealth systems for everyone, everywhere to improve access to quality health services, and allow for better health and well being of all citizens and better health systems management.

We believe eHealth should support: – Personal, family, community, public health services and

preventative interventions, particularly in resource-poor environments

– The most relevant health research, information and education, for health providers, researchers, policy makers and citizens

– Appropriate, complete, consistent and interoperable health information systems, that integrate public health and clinical requirements for overall health systems management and stewardship.

1

2

3


“eHealth” a broad and diverse realm of efforts

eHealth:

the use of information and communication technologies (ICT) to improve health

Different types of eHealth initiatives include, but not limited to:Different types of eHealth initiatives include, but not limited to:

Health information systems• Public health informatics:

• Support for disease prevention• Disease and intervention surveillance (e.g. PDAs to community health

workers for disease surveillance)• National health info systems to detect/track global threats to public health

• Health and clinical informatics:• Electronic health records (EHR), electronic medical records (EMR), patient

health records (PHR)• Decision support for healthcare professionals

• Health system administration and operations• Pharmacy and supply chain management systems• Laboratory systems (e.g. electronic ordering, transmission processing)• Clinical administration software (e.g. billing)

Healthcare and expertise• Telemedicine / telehealth

Health research, advisories and education• eLearning for physician, nurse, healthcare personnel training• Access to research for healthcare personnel• Patient support and information (SMS reminders for drug compliance, online

health information, etc.)• Decision support for healthcare professionals


Variety of challenges to reaching vision

Barriers and impediments

to eHealth advancement

Little capacity for developing and managing health information technology

Prohibitive policy environment

Optimal eHealth

development path unclear

System is fragmented – donors and other stakeholders push for narrow, specific solutions without interoperability considerations

• Leads to inefficient use of funds• Creates program stovepipes

Lack of private sector providers due to low market incentives threatens sustainability, independence

Immaturity and youth of

eHealth effort in developing

countries

Lack of awareness about value of eHealth and breadth of possible solutions

Lack global forums with all relevant stakeholders in which to discuss progress, issues and learnings

STOVEPIPINGSTOVEPIPING

The most common types of intelligence collection, and to some extent processing, which are commonly found in "stovepipes", include signal intelligence (SIGINT), imagery intelligence (IMINT), and human intelligence (HUMINT)

Stovepiping is a metaphorical term which recalls a stovepipe's function as an isolated vertical conduit,has been used, in the context of intelligence, to describe several ways in which raw intelligence information may be presented without proper context. The lack of context may be due to the specialized nature, or security requirements, of a particular intelligence collection technology.


Solution areas grounded in domains of eHealth applications

“Path to Interoperability” -finding optimal development path to maximize eHealth potential•“eHealth Policies” and “Capacity Building” address the enabling environment to lower the barriers and impediments to eHealth diffusion and advancement•“Electronic Health Records”, “mHealth”, “Public Health Informatics” and “Access to Information” provide grounding in applications that strengthen health systems

EHR mHealth PHI A2K

Interop. Markets

Optimal development path

eHealth applications

PoliciesCapacit

y building

Enablers


Connected health information network will require interoperability across several dimensions

Across programs Across geographies

Across points of care Across technologies

Census

TB

Malaria

HIV/ AIDS

Hospital

Health clinic

Community health worker

Metcalfe’s LawMetcalfe’s Law Examples of dimensions to be addressedExamples of dimensions to be addressed

The value of a network (e.g. Telecomm) is proportional to the square of the number of users of the system (n²)

Early stage of eHealth in much of developing countries is an advantage – possible to take action now

Hypothesis: Collaborative action necessary for Hypothesis: Collaborative action necessary for successsuccess

• Collaboration can achieve synergy through united action– Branding: uniting all eHealth-related efforts to increase awareness– Funding coordination: drives alignment on key issues, reduces redundant activities– Mitigate HR constraint: limited group of experts in this field

1

2

3

• Technology companies• Biopharmaceutical companies• Entrepreneurs• Research and academia• Others?

Fostering spread of eHealth requires multiple, interconnected efforts• HCIT capacity building required to support many eHealth efforts• National policies needed to support all types of programs• Emerging platform technologies, e.g. mobile health, span multiple areas of focus public

health, clinical and patient-centered informatics

Multi-player, multi-sectoral initiative needed• Ministries of health and other

representatives of target countries• Private donors/foundations• Non-governmental organizations• Multilateral donor/aid organizations

Goal : engage stakeholders on collaborative action Goal : engage stakeholders on collaborative action to address challenges facing eHealth effortsto address challenges facing eHealth efforts

Capacity building

• help countries build and sustain HR capacity to manage, maintain and develop eHealth solutions

Policy advocacy• develop enabling policy guidelines• advocate to and/or advise countries on policy development

Standards support

• identify/advocate/implement critical data standards to ensure data quality and interoperability

Funding coordination

• raise funds for eHealth, reduce redundant activities and increase pool of funding

• align funders on key issues (e.g. interop. standards), channel funding as needed

Market-making

• connect “buyers” and “sellers” of eHealth solutions– educate consumers on portfolio of available

applications– aggregate demand for eHealth solutions– potentially provide base level of freeware / starter kits

Key collaborative actionsKey collaborative actions

Enablers

Policy

Cap. build.

Optimaldevelopmentpath

Interop

Market

Com

mu

nic

atio

nst

and

ard

s

Info

rma

tion

stan

dar

ds

Example: hierarchy of eHealth standards Example: hierarchy of eHealth standards supported by communication standardssupported by communication standards

SNOMED

TCP

XML

HL7 v2.51

IP

HTTP

TermTerm

Systematized Nomenclature of Medicine

Health Level Seven

eXtensible Markup Language

Hypertext Transfer Protocol

Transmission Control Protocol

Internet Protocol

DescriptionDescription

Systematically organized collection of medical terminology covering most areas of clinical information

Enables the exchange, management and integration of healthcare information

Facilitates sharing of structured data across different information systems

Used to transfer or convey information on the World Wide Web

Provides reliable, in-order delivery of a stream of bytes

Data-oriented protocol used for communicating data across the internet

Standard Standard First useFirst use

1987

2003

1997

1996

1974

1977


11(#total)

• The Future of Healthcare - The banking metaphor• Existing Health on the Web• eHealth - terminology• Transmural Care• Electronic Medical Records (EMR)• Medical Records - Access• Clinical Decision Support Systems • Telemedicine - Case Studies• eHealth Standards • eHealth / eScience : Cancer Diagnosis• Benefits of eHealth• Medical Errors• Why is eHealth Adopted Slowly?• New sources of "health"


12(#total)

eHealth - The Future of Healthcare The banking metaphor

• Most transactions carried out by the customer

• Centralisation of specialist services

• Decentralisation of non-specialist services


13(#total)

Existing Health on the Web

Access to accurate information can lead tomore knowledgable, empowered, less anxious patientsmore participatory health decisionsbetter care as patient and doctor become partners

Mis-information can lead to confused and angry patientsbad decisions, mis-placed hope, worse care, harm

Privacy violations can cause emotional and economic damage


14(#total)

eHealth

“Healthcare which is supported by electronic processes”

Other terms:– Healthcare informatics or Health Information Technology (HIT)– Medical Information Systems (MIS)– Biomedical informatics (also includes Bioinformatics: gene

sequencing etc.)


15(#total)

“Healthcare which is supported by electronic processes”

eHealth includes:

– Electronic Medical Records: easy communication of patient data between different healthcare professionals (GPs, specialists, care team, pharmacy)

– Telemedicine: do not require a patient and specialist in same physical location.

– Decision support systems in healthcare • Data can be analysed to provide alerts, reminders and real-time decision aids

– Evidence Based Medicine: • The application of the scientific method to medical practice• Check if diagnosis is in line with scientific research. • Data can be kept up-to-date.

– Citizen-oriented Information Provision: for both healthy individuals and patients

– Specialist-oriented Information Provision: best practice guidelines from latest medical journals.

– Virtual healthcare teams: collaborate and share information on patients through digital equipment (for transmural care).


16(#total)

Transmural Care

Transmural: Care should not stop at the walls of the hospital– Both intra- and extra-mural, thus ‘transmural care’.– Care before, during and after the hospital stay. – Cooperation and coordination among local practitioner,

hospital, home care and rehabilitation centres– Patient part of an agreed programme - protocols and

standards.


17(#total)

Electronic Medical Records (EMR)(also called Electronic Health Record (EHR))

– Access of patient data by clinical staff at any given location – Accurate and complete claims processing by insurance companies – Building automated checks for drug and allergy interactions – Clinical notes – Prescriptions – Scheduling – Sending and viewing labs

Two types of record:– “Born digital" record : information originally entered in electronic format– “Digital format” record : originally produced in a hardcopy form (x-ray film, photographs, etc.),

scanned or imaged and converted to a digital form.

Also: Personal Health Record (PHR) - stored and maintained by the patient.– Issue: Home computer vulnerable to attack


18(#total)

Electronic Medical Records (EMR)

Maintaining Records– May be required many years after a patient’s death

• Insurance claims or murder investigation• Investigate illnesses within a community

– industrial or environmental disease – doctors committing murders

– need for periodic conversion and migration to ensure the formats they were captured in remain accessible

– Media degrades– Media becomes obsolete– protection of privacy is a major concern - need privacy and security

policies


19(#total)

Clinical Decision Support Systems

• Software to aid clinical decision-making: characteristics of patient are matched to knowledge base,

recommendations are presented to the clinician/patient

• Objectives:– Diagnostic support– Drug dosing– Preventive care reminders– Disease management (diabetes, hypertension, AIDS, asthma)– Test ordering, drug prescription


20(#total)

Clinical Decision Support Systems

• Methods:– rule-based, bayesian network, neural network, fuzzy logic, genetic

algorithms, case-based reasoning, etc.

• Forward reasoning (data-driven) use if sparse data– start with data, execute applicable rules, see if new conclusions

trigger other rules:• if high WBC AND cough AND fever AND etc. => pneumonia• if pneumonia => give antibiotics, etc.

• Backward reasoning (goal-driven) use if lots of data– start with “goal rule,” determine whether goal rule is true by

evaluating the truth of each necessary premise • patient with lots of findings and symptoms• is this lupus? => are 4 or more relevant criteria satisfied?


21(#total)

Telemedicine

“The delivery of medicine at a distance.”

Two basic forms:– Live telemedicine - videoconference link– Store-and-forward telemedicine - transmit for assessment offlineTypical Telemedicine interaction: store and forward followed by live

interaction.

Data types– text (e.g. patient's notes)– image (e.g. x-ray) Telemedicine often relies on images (still or moving)

Equipment– general purpose (e.g. PCs)– specialist (e.g. electronic stethoscope)


22(#total)

Telemedicine (contd.)

Telemedicine most useful when – Specialist services are in very high demand or– Patients are extremely isolated

Home care is often delivered by telemedicine– Automatic monitoring and pill dispensing etc.

Telesurgery may also be considered as a subset of telemedicine.

– Patient operated on by remotely controlled robotic arms etc.


23(#total)

eHealth / eScience : Cancer DiagnosisTelemedicine on the Grid– Multi-site videoconferencing – Real-time delivery of microscope imagery– Communication and archiving of radiological

images• Supports multi-disciplinary meetings for the

review of cancer diagnoses and treatment.

Remote access to computational medical simulations of tumours and other cancer-related problems

Data-mining of patient record databasesImproved clinical decision making.

Currently clinicians travel large distances

Grid technology can provide access to appropriate clinical information and images across the network.


24(#total)

Benefits of eHealth– Reduced record keeping expenses– More accurate data

• No poor handwriting problems– Automated sharing among patients and provider

• Empower the patient to manage their own health - via Internet information and decision support tools

– Reduced office visits to get results– Avoidance of duplicating tests– Automatic summarisation/graphical displays of context-

relevant information to the physician


25(#total)

Benefits of eHealth (contd.)

– Decision Support Tools -> Improved decisions– Remote access to data - e.g. ill while travelling– Improved workflows– Decreased risk of malpractice suits– Ability to mine large record databases

• Research causes of disease• Assess effectiveness of treatment programmes/drugs• Monitor outbreaks of diseases• Easier to conduct clinical trials and rapidly incorporate research results

in decision support tools


26(#total)

Why is eHealth adopted slowly?

– Lags behind other industries by 10-15 years – Complex regulations - e.g.

• Patient records• Privacy laws

– Lack of interoperability/standards– Doctors reject IT systems

Risks– Potential for errors due to software bugs– Highly coupled systems - greater risk of catastrophe– Decision support systems could lead to mass produced

mistakes– Privacy - data vulnerable to attack


Presentation

• HL7• MITA, HL7, CMS, DHHS, ONC, FEA -> alignment of healthcare architecture• MITA Business Architecture -> Information Architecture

– MITA Enroll Provider (HL7 MITA WG Example)– MITA Inquire Member Eligibility (Gateway 5010 Project)

Business Architecture

Technical Architecture

Information Architecture


HL7• An international standard development organization established

more than 20 years ago.• Enables interoperability of healthcare information.• Creates standards for the exchange, management, and

integration of electronic healthcare information.• Develops specifications, e.g., a messaging standard that

enables disparate healthcare applications to exchange key sets of clinical and administrative data. (HL7 does not develop software).

• Why Health “Level Seven”? – this refers to the highest level of the International Organization for Standardization (ISO) communications model for Open Systems Interconnection (OSI) – the application level.– The seventh level supports such functions as security

checks, participant identification, availability checks, exchange mechanism negotiations and, most importantly, data exchange structuring.


HL7 TodayVersion 3 Reference Information Model (RIM v3)• Messages evolved over several years using a "bottom-up" approach that

has addressed individual needs through an evolving ad-hoc methodology. • Many optional data elements and data segments, making it adaptable to

almost any site. • The optionality forces implementers to spend more time analyzing and

planning their interfaces to ensure that both parties are using the same optional features.

• Well-defined methodology based on a reference information (i.e., data) model. It will be the most definitive standard to date.

• Rigorous analytic and message building techniques and incorporating more trigger events and message formats, resulting in a standard that is definite and testable, and provide the ability to certify vendors' conformance.

• Uses an object-oriented development (OOD) methodology and a Reference Information Model (RIM) to create messages. The RIM is an essential part of the HL7 Version 3 development methodology, as it provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.


Steering Divisions: Foundations & Technologies

Provides fundamental tools and building blocks– Conformance

– Infrastructure & Messaging

– Implementable Technology Specifications (ITS)

– Java

– Modeling & Methodology

– Security

– Services Oriented Architecture (SOA)

– Templates

– Vocabulary


HL7 DiversifiedHL7 started with and is traditionally thought of as “messaging”. For most

of its life, however, HL7 has also produced more than messaging standards.– Electronic Data Exchange in Healthcare Environments (i.e.

“messaging”) (v2 and v3)– Visual/Context Integration (CCOW)– Version 2.x XML (XML encoding of HL7 messages)

• Clinical Context Documentation Implementation Guide (CCD)– Electronic Health Record System (EHRS) Functional Model– Personal Health Record System (PHRS) Functional Model– Services (i.e., Services as related to a Services Oriented

Architecture


Cooperation with Other Standards Developing Organizations

HL7 cooperates closely with other standards developers, such as:– Accredited Standards Committee X12N (AXC X12N)– Systemized Nomenclature of Medicine Clinical Terms (SNOMED CT)– Digital Imaging and Communications in Medicine (DICOM)– eHealth Initiative (eHI)– Logical Observation Identifiers Names and Codes (LOINC)– National Council for Prescription Drug Programs (NCPDP)– Object Management Group (OMG)– Health Information Technology Standards Panel (HITSP) – Continuity of Care Document (CCD) – XML standard for medical

information summarization


Work Group; TeamsHL7 MITA Work Group (HL7 MITA WG)

The HL7 MITA Project Work Group is focused on creating the initial MITA Business Process Models and Information Model which will become the MITA Information Architecture.

– HL7 MITA Project Work Group• Business Process Team

– Use Cases, Storyboards, additional requirements for v2.01 business process templates

• Data Analytics Team– Information Model Data analysis and database

• Modelers Team– Diagrams and models for business processes

• Vocabulary Team– Medicaid specific vocabulary

• Education and Training Team– Documentation and assistance for newcomers; lessons learned; best

practices


MITA Architecture Governance Structure

MITA Architecture Review Board

MITA Business Architecture

Review Board

MITA Information Architecture

Review Board

MITA Technical Architecture

Review Board

•Business Process

•Business Capability

•S-SA process

•Data Models

•Vocabulary

•Mapping to Standards

•Data Management Strategy

•Service definitions

•Infrastructure definitions

•Technical processes

•Technical capabilities

•Mapping to Standards

•MITA Standards

•Framework updates


Supporting Review Organization Activities

• Supporting Organization – TAC• Activities –

– Technical function recommendations– Technical Function capability level recommendations– Technical Function Information Model

recommendations– Technical Service WSDL recommendations– Harmonization recommendation between MITA and

Technical – Interface between MITA and technical industry


Multi-Architecture Impact

NMEH

HL7-MITAProject

TAC

BARB

IARB

TARB

ARB

MITA Users


The Big Picture

NMEH

HL7-MITAProject

TAC

BARB

IARB

TARB

ARB

MITA Users

STAG

New Bus Proc

Other DSMOs

HL7 HL7Healtth DataCommunity

Technical Implementer

IndependentInformation Spec.

State BusinessSMEs


Federal Enterprise Architecture (FEA)


Healthcare Standards EnvironmentFEAParticipates in


HL7 MITA Work Group Process Flow (Draft)


Framework is Essential

Healthcare Development Framework (HDF)

Version 1.2Published on: April 23rd, 2008

HL7 Development Framework


MITA Information Models• The Business Process Model is derived by analyzing the

Medicaid Business Requirements in terms of the Concept of Operations.

• The Business Process Model is neutral with respect to any organization, location, staff, outsourcing, and automation.

• Applying the Medicaid Maturity Model (MMM) to the Business Process Model yields the Business Capabilities.

• Business Capabilities show the evolution of Business Processes over time.

– UML

– Use Case models

– Activity models

– Message schemas (HMD, CMET)

– Information models (DMIM, RMIM)

– Abstract WSDL


HL7 V3 Message Development Methodology: How

• Use Case Modeling– Produce a storyboard example– Generalize the storyboard example into a storyboard

• Information Modeling– Define classes, attributes, datatypes, and relationships– Define vocabulary domains, code systems, and value sets– Define states, trigger events, and transitions

• Interaction Modeling– Define application roles– Define interactions

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


MITA Information Architecture Models• The Business process/ Business capability combinations are the

cornerstone of the Business Architecture and the driver for the Technical Architecture.

• Business Capabilities map to the Conceptual Data Model.• The Conceptual Model is the basis for the Logical Data Model.• New functional requirements may change the Business Capabilities.• Business Capabilities may update the Conceptual Data Model, and

thereby evolve the Logical Data Model.• The Logical Data Model can be expressed as a WSDL.• The Logical Model will be implemented via a Physical Model via a

information technology specification such as Java or XML.– Business Model– Conceptual Model– Logical Model– Physical Model

Note: CMS will provide Medicaids with specifications for making their systems interoperable, and reusable.CMS does not mandate types of software.


Business Area

Technical Area

Technical Function

Technical Capability

Conceptual Data Model

LogicalData Model

Business Capability

Business Process

Medicaid Mission and Goals MITA Principles, Goals, and Objectives

Physical Data Model


Business Capability Matrix

Provider enrollment staff spend hours verifying provider

credentials or fail to do primary credentialing verification

because of difficulty and liability risk

Provider enrollment staff use automated, web-based, online credentialing and sharing of

primary source verification with other state health programs and

other Medicaid agencies

The enrollment process is automated by an interface with

the RHIO Provider Directory which invokes a credential

verification service

5 YEARS

LE

VE

L 1

LE

VE

L 3

LE

VE

L 5

NOW5 YEARS 10+ YEARSNOW

Provider Enrollment – Credentialing Step


Evolving Enroll Provider Business Capability

Level 1

Level 2

Level 3

Level 3

Level 4

Level 4

Level 5

Receive paper enrollment application; verify via phone; manual processing

Real time rules driven enrollment /verification; one-stop collaboration

Outcomes based enrollment; continuous verification against national databases

NOW 5 YEARS 10+

Example of Maturing Business Capabilities…

Use proprietary EDI for enrollment /verification; legacy MMIS hard coded rules

Enrollment/verification via RHIOs; access clinical record


Challenges with the Art/Science of Modeling

• Evolution to Unified Modeling Language (UML)– Object-Oriented Analysis (OOA)– Object-Oriented Design (OOD)– Object-Oriented Analysis and Design (OOAD)– Object-Oriented Software Engineering (OOSE)

– UML» General purpose modeling language that tries to

achieve compatibility with every possible implementation language.


UML v2.0

UML Modeling

Structure Diagrams: what things must be in the system being modeled.

Behavior Diagrams: what must happen in the system being modeled.

Interaction Diagrams: subset of behavior diagrams that emphasize flow of control and data among the things in the system being modeled.


HL7 Modeling Hierarchy


RIM

(1)Define aD-MIM

D-MIM

(2)Define aR-MIM

R-MIM

(3)Create

an HMD

HMD

RIMReference Information Model

D-MIMDomain Message Information Model

R-MIMRefined Message Information Model

HMDHierarchical Message Definition

HL7 V3 Message Design Models

• Select RIM classes to be included in D-MIMSelect RIM classes to be included in D-MIM

• Clone subset classes of the RIMClone subset classes of the RIM

• Select a subset of class relationshipsSelect a subset of class relationships

• Select a subset of class attributes Select a subset of class attributes

• Select a subset of attribute data types and domainsSelect a subset of attribute data types and domains

• Create clones of D-MIM classes and attributesCreate clones of D-MIM classes and attributes

• Assign alias class and relationship role namesAssign alias class and relationship role names

• Eliminate unnecessary class hierarchiesEliminate unnecessary class hierarchies

• Finalize class relationships and cardinalityFinalize class relationships and cardinality

• Finalize attribute data types and domainsFinalize attribute data types and domains

• Select a root class for the messageSelect a root class for the message

• Arrange classes and attributes hierarchicallyArrange classes and attributes hierarchically

• Declare inclusion and repetition constraintsDeclare inclusion and repetition constraints

• Declare data type and domain value constraintsDeclare data type and domain value constraints

• Assign message element namesAssign message element names


ReferenceInformation

Model


Model

DatatypeSpecification


VocabularySpecificationVocabulary

SpecificationReference

Models

InteractionModel

InteractionModel

DesignInformation

Model

DesignInformation

Model

CommonMessage Type

Model

CommonMessage Type

Model

DesignModels

HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition

ImplementationTechnology

Specification


Specification

MessageSpecifications

MessageProfile

Specification

MessageProfile

Specification

LocalizedMessage

Specification

LocalizedMessage

Specification

MessageConformanceStatements

MessageConformanceStatements

ConformanceProfiles



Model


Model



VocabularySpecificationVocabulary

Specification

Reference Models

The HL7 Reference Information Model is the information model from which all other information models and message specifications are derived.

The HL7 Vocabulary Specification defines the set of all concepts that can be taken as valid values in an instance of a coded attribute or message element.

The HL7 Datatype Specification defines the structural format of the data carried in an attribute and influences the set of allowable values an attribute may assume.


InteractionModel

InteractionModel

DesignInformation

Model

DesignInformation

Model

CommonMessage Type

Model

CommonMessage Type

Model

Design Models

An Interaction Model is a specification of information exchanges within a particular domain as described in storyboards and storyboard examples.

A Domain Information Model is an information structure that represents the information content for a set of messages within a particular domain area.

A Common Message Type Model is a definition of a set of common message components that can be referenced in various message specifications.


HierarchicalMessage

Definition

HierarchicalMessage

Definition

MessageType

Definition

MessageType

Definition


Specification


Specification

Message Specifications

An Hierarchical Message Definition is a specification of message elements including a specification of their grouping, sequence, optionality, and cardinality.

A Message Type Definition is a specification of a collection of message elements and a set of rules for constructing a message instance.

An Implementation Technology Specification is a specification that describes how to construct HL7 messages using a specific implementation technology.


MessageProfile

Specification

MessageProfile

Specification

LocalizedMessage

Specification

LocalizedMessage

Specification

MessageConformance

Statement

MessageConformance

Statement

Conformance Profiles

A Localized Message Specification is a refinement of a HL7 message specification standard that is specified and balloted by an HL7 International Affiliate.

A Message Profile Specification is a description of a particular or desired implementation of an HL7 Message standard or Localized Message specification.

A Message Conformance Statement is a comparison of a particular messaging implementation and an HL7 message standard, localization, or profile.


HL7 V3 Methodology:

What and How

Use Case Modeling

Interaction ModelingService Definition

Message Design

Information Modeling

RIM

Restrict

R-MIM

Serialize

HMD

Restrict

MessageType

Example

Storyboard

StoryboardExample

D-MIM

Derive

ApplicationRole

Sender Receiver

TriggerEvent

Triggers

Content

InteractionReferences


Domain Analysis Model (DAM)

class 3.7 DAM Artifacts


«optional»Use Case Analysis

Story board

Information Model (Analysis)

Process Flow

«optional»Business Rules Description

Business Trigger Analysis

«optional»Glossary of Classes and Attributes

class 3.7 DAM Artifacts


«optional»Use Case Analysis

Story board

Information Model (Analysis)

Process Flow

«optional»Business Rules Description


«optional»Glossary of Classes and Attributes



class 4.2: Context

Specification DesignRequirements Analysis

Domain Analysis Model

Stakeholder/Business Requirements

Business Process Model Analysis

Process Flow (Activity Diagram)

Use Case Model

Information Model


(from Annex A. Domain Analysis Example)

Specification Dev elopment

Requirements Analysis

Specification Design

Domain Analysis Model

Design Information Model - DIM

Message Structure - CIM

Localization - LIM

Dynamic Model

Technology-Specific Artifacts

(from Annex A. Domain Analysis Example)


Design Dynamic Modelact 4.4.2: Design Dynamic Model

Analyst :Business Analyst Facilitator :HL7 Modeling Facilitator


(from 3.7 Artifacts)

DefineInteractionsTriggers

Specify the type ofinteractions and system

roles

Design Information Model (DIM)

(from 4.7.1 Information Modeling Artifacts)

«UML State chart»State Transitions

(from 4.7.2 Dynamic Modeling Artifacts)

«UML Activity Di...Sending Process

Description


Document notificationtriggers

Document query or request pre-conditions

«UML Sequence Diagra...System Interaction Description


Document receiv er's responsibilities

«UML Activity Di...Receiv ing Process

Description(from 4.7.2 Dynamic Modeling Artifacts)

Rev iew Dynamic Model Design

Constrained Information Model

(CIM)

(from 4.7.1 Information Modeling Artifacts)

Interface Specification


Publish Design Model andReports

(from 4.4 P rocess)

Dynamic Model Artifact

Process Activit y

Information Model Artifact

Runtime Artifact

Legend Generate TechnologySpecific Artifacts

(from 4.4.1 Information Model Design )

Deriv e System Functions

Functional Model


«input»

«input»

«input»

«input»

parameter specification


Medicaid Business Process Model

Medicaid Business Process Model

Care Management

Contractor Management

Operations Management

Member Management

Provider Management

Program Management

Program IntegrityManagement

Business Relationship Management

Enroll MemberDisenroll Member

Inquire Member EligManage Member Info

Manage Member Comm

Award ContractClose out Contract

Manage Contractor CommManage Contractor InfoInquire Contractor Info

Identify Candidate CaseManage Case

Apply AttachmentAudit Claim-EncounterManage Drug Rebate

Prepare EOBCalculate Spend-down

Enroll ProviderDisenroll Provider

Manage Provider CommManage Provider Info

Perform Provider Outreach

Establish CaseManage Case

Manage Medicaid Pop Health

Establish RelationshipManage RelationshipManage Relationship

CommunicationsTerminate Relationship

Maintain State PlanFormulate Budget

Manage Rate SettingManage 1099sManage FFP


Use Triggers to Reference the Process

New Enrollment

Triggers


Static Model• Collect relevant "data in motion" for a business process.

• Example: For the Enroll Provider business process, collect relevant provider data from NPI, X12 transaction, and MMIS data dictionaries.

• Develop Conceptual Data Model (CDM) - e.g., provider is a role class (with attributes) played by an entity class with attribute and scoped by one or more entities (credentialing, supervision, enumeration etc.)


Dynamic Model – Use CaseStart with MITA Business

Process Templates

• Consider Use Case Diagram

• Consider Business Process Diagram

• Actors = Application Roles

• Inputs and Outputs = Messages

• Events = Trigger Events prompting interchange

Staff/MMIS verifies provider’scredentials and checks NPS,NPDB and HIPDB status real

time before enrolling

NPS, NPDB, HIPDBMMIS


Dynamic Model

NEXT:• Develop activity diagram for the

business process steps and exceptions

• Determine – Pre-condition– Post-condition

• Add – Trigger Events– Receiver Responsibilities

(Role of Receiving Application)

– Update requirements

ad Activ ity Diagram

MMIS NPS

Initiate NPS Query Interface

NPS Query

Receive Query

Find NPI & PT

«datastore»

NPS Prov ider Record

Provider Indenti ty Confirmed?

Prov ider Enroll Info

Reject Query

Receive Reject Query

Provider Enrol lment Rejection

AggregateNPS Data

Query Response

Receive Query

Response

NPS PT Align with MITA PT?

«datastore»

Prov ider Record

Xw alk toMITA PT

Activi tyFinal

Load NPI

Provider Enrol lment Accepted

Activi tyFinal

Yes

No

Yes


MessagingFinding the correct data element from HL7 RIM

Example of Enroll Provider Step 12: Request that the Manage Administrative and Health Services Contract business process negotiate contract and send enrollment determination notifications.


Example of HL7 to MITA Messaging


HL7 v3 Static Models = MITA Logical Model


Serialize –> The Physical Model

Serialize into Message Types from which XML Schema is generated.

Transform

Serialized Table Format XML Schema


Inquire Member Eligibility Input Messages (Class Diagram)

POLITEHNICA University of BucharestPOLITEHNICA University of BucharestFaculty of Control and ComputersFaculty of Control and ComputersInquire Member Eligibility Business

Process (Activity Diagram)


Accomplishments• Defined the Technical Services needed to completely implement

several MITA business services.• Demonstrated the ability to coordinate with at least one other

major industry initiative.• Demonstrated a working proof of concept.• Collaborated with the MITA HL7 Work Group.

– Reviewing CAQH Provider DataSource, which has over 600K+ providers, and is free of charge to providers. Its mission is to reduce the administrative burdens of provider data collection processes like credentialing; HITSP. Others are considering uses for this database, e.g. emergency response, that providers could opt-into.

• Define the process of adopting a MITA Technical Service

7373© 2002-2008 Health Level Seven ®, Inc. All Rights Reserved. HL7 and Health Level Seven are registered trademarks of Health Level Seven, Inc. Reg. U.S. Pat & TM Off

HL7 and Service-oriented HL7 and Service-oriented Architecture (SOA)Architecture (SOA)

TopicsTopics

• HL7 Vision and Mission• Understanding Service-oriented Architecture

(SOA)• The case for Healthcare SOA Standards • Introducing HSSP• Status of Standards Work

First, A Few Terms…First, A Few Terms…

• DSTU = Draft Standard for Trial Use• HL7 = Health Level Seven • HSSP = Healthcare Services Specification Project • OMG = Object Management Group• OHT = Open Health Tools• SOA = Service-oriented Architecture

SOA SOA ≠≠ Web Services Web Services

SOA Web Services

Is a technology platform? No Yes

Is a transport protocol? No Yes

Primary ownership is business-line owned?

Yes No

Affects workflow and business processes?

Yes No

Is an enabler for business and IT transformation?

Yes Yes

Is an industry standard? No Yes

How How is is SOA different from messaging?SOA different from messaging?

• A common practice in healthcare, just not yet in healthcare IT• Many key products use them but do not expose interfaces • Ensures functional consistency across applications• Accepted industry best practice • Furthers authoritative sources of data• Minimizes duplication across applications, provides reuse• Messages can be either payloads in or infrastructure beneath

services• Service-oriented architecture provides the framework for

automation of common services• Still, SOA has to be done well. It is cheaper and easier than

ever to create badly designed applicationsSo:

Why SOA Healthcare Standards?Why SOA Healthcare Standards?

Why develop healthcare SOA standards?Why develop healthcare SOA standards?

• Healthcare organizations are being driven to interoperate

• “Messaging” is not the ideal approach for every interoperability challenge

• SOA has demonstrated viability and benefits for many organizations and in many vertical-markets

Understanding InteroperabilityUnderstanding Interoperability

Ab

ilit

y to

Int

erop

erat

e

High

Low

SOA In Action…SOA In Action…An Identity Management ExampleAn Identity Management Example

Local/Regional Domain 2

Regional Identity Service (EIS)

service client

Implementation

Interface

National Identity Service

National/Master Domain

service client

Interface

Implementation

External organization’s system

Local/Regional Domain 1

“Local” Identity Service

service client

Implementation

Interface

1. Query local domain: entity found locally

2. Query local domain: entity not found locally, retrieve from master domain

3. Query master domain: retrieve linked entities from master domain

Scenarios

4. External System Query: Retrieve from master domain

1.1

1.2

1.3

1.4

2.1

2.2

2.3

2.5

2.6

2.4

3.1

3.2

3.3

3.4

4.1

4.2

The Healthcare Services Specification Project The Healthcare Services Specification Project (HSSP)(HSSP)

• An effort to create common “service interface specifications” tractable within Health IT

• A joint standards development project involving Health Level 7 (HL7) and the Object Management Group (OMG)

• Its objectives are:– To create useful, usable healthcare standards that address

functions, semantics and technologies– To complement existing work and leverage existing

standards – To focus on practical needs and not perfection– To capitalize on industry talent through open community

participation

The Benefits of HSSP Standards… The Benefits of HSSP Standards…

• Define industry standard behaviors for healthcare-oriented service functions

• Eliminate “different flavors” of web services from occurring in different organizations

• Rapid-pace stds development: ~18-24 months• Methodology embracing cross-group standards

development

HSSP is part the bigger HIT landscape…HSSP is part the bigger HIT landscape…

HSSP

HL7 Domain Committees

OMG

HITSP

National Programs (e.g. ONC, NEHTA)

CEN

OpenEHR

OHT

IHE

Methodology (SSF),DSTU Feedback,

Consultative support

SFMs, Info Models,

Requirements,Service Profiles

Policy

Service Profiles

Methodology,HL7/SOA Harmonization

SOA Interoperability Specifications

Use Cases,Requirements

TechnicalSpecifications,RFP process

Use Cases,Candidate Standards

Info Models,Semantic Profiles

SOA Interop Specs

RFPRequirements

Integration Profiles,Conformance Testing,

Interoperability Validation

TechnicalSpecifications

Open SourceRef Implementations,

Tools

SOA Interoperability Specifications,

Use Profiles

Cross-Organizational Standards DevelopmentCross-Organizational Standards Development

OMG

HL7

HL7 Draft Stds for Trial Use

Service Functional Model

OMG Request for Proposal

(RFP)

Technical Specification

ANSI Standard

SummarySummary

““How do you know that the How do you know that the [web-] services you’re [web-] services you’re building are not just the next building are not just the next generation of stovepipes?”generation of stovepipes?”

““How do you know that the How do you know that the [web-] services you’re [web-] services you’re building are not just the next building are not just the next generation of stovepipes?”generation of stovepipes?”

Stovepiping is a metaphorical term which has been used, in the context of intelligence, to describe several ways in which raw intelligence information may be presented without proper context.


Thank youThank you

impact of information technology on the quality of health services

Documents

ehealth diffusion

spread of ehealth

stage of ehealth

ehealth solutionspolicy

context of intelligence

mobile health

public health informatics

ehealthrelated efforts