Standards & interoperability M. Giacomini DIBRIS ... · Interoperability Semantic Interoperability Technical Interoperability SO A Ability to transport data from system A ... Interoperability

Standards & interoperabilityM. Giacomini

DIBRIS - University of Genoa

E-Health – Medicina Digitale

Learning Health System

“In the learning health system, progress in science, informatics, and care culture align to generate new knowledge as an ongoing, natural by-product of the care experience, and seamlessly refne and deliver best practices for continuous improvement in health and health care.” Institute of Medicine (IOM)

Interoperability

«the interoperability is the ability of two or more systems or components to exchange information and to use the information which has been exchanged»

Process Interoperability

SemanticInteroperability

TechnicalInteroperability

SOASOA

Ability to transport data from system A to system B

Ability to transport data from system A to system B

Service Oriented Architecture (SOA)

Web Service = A software that presents functionalities and information available on the web for clients through well defned interfaces by standard protocols Simple Object

Access Protocol (SOAP)

Simple Object Access Protocol (SOAP)


Web Service = A software that presents functionalities and information available on the web for clients through well defned interfaces by standard protocolsWeb Service Description Language (WSDL)

Web Service Description Language (WSDL)


• Flexibility → integration and aligning of old and new systems within a coherent architecture.

Interoperability





Standards for clinical data exchange

Standards for clinical data exchange

Ability to assure that two systems interpreter data in the same way

Ability to assure that two systems interpreter data in the same way

EHR and Standard

1. HL7 Version 3 Clinical Document Architecture Release 2 (HL7 v3 CDA R2)

2. CEN/ISO 13606 3. openEHR

Chosen by governmental authorities

Chosen by governmental authorities

Reference Information Model (RIM)

1. Entity

2. Act

Entity vs Act

involved in 0,…*

involves1…*

Example: one person (entity) is involved in a laboratory test (act).Example: one person (entity) is involved in a laboratory test (act).

Entity vs Act

involved in 0,…*

involves1…*

How the person is involved: as a patient or as a physician?

3. Role

Entity vs Act

A person (entity) plays the role of physician (role) in a laboratory test (act).A person (entity) plays the role of physician (role) in a laboratory test (act).

1 0,..* 1..* 0,..*

involvesplays

Entity vs Act

1 0,..* 1..* 0,..*

coinvolgegioca

What type of physician?

4. Participation

Entity vs Act

A person (entity) plays the role of referring (participation) physician (role) for a laboratory test (act).

A person (entity) plays the role of referring (participation) physician (role) for a laboratory test (act).

1 0,..* 1 0,..*gioca

0,..* 1

5. ActRelationship

A laboratory test (act) contains (actRelationship) observations (act).A laboratory test (act) contains (actRelationship) observations (act).

6. RoleLink

A person can play the role of referring physician (role) only if he/she is afliated (RoleLink) to a clinical entity (entity).

A person can play the role of referring physician (role) only if he/she is afliated (RoleLink) to a clinical entity (entity).

D-MIM

Domain Message Information Model: subset of the RIM that includes a series of classes, attributes and relations that can be used to create messages in a specifc Domain.

Domain Message Information Model: subset of the RIM that includes a series of classes, attributes and relations that can be used to create messages in a specifc Domain.

R-MIM

Refined Message Information Model: subset of the D-MIM that is used to express the information content of a message or of a group of messages within a specifc Topic.

Refined Message Information Model: subset of the D-MIM that is used to express the information content of a message or of a group of messages within a specifc Topic.

HL7 v3 CDA R2

Header:• Personal patient data,• Info on the hospital / department,• Info on the medical entity• Referral type• Informed consent

Body:• Observed data (human readable)• Coded observed data

Interoperability





HSSPHSSP

Ability of two or more business processes within a system to worktogether as much automated as possible, minimizing human user interaction

Ability of two or more business processes within a system to worktogether as much automated as possible, minimizing human user interaction

A business process is a set of interacting activities (working within a business organization) that create value transforming resources (considered as input of the process) in a product (the output of the process) thought for a specifc subject within or outside the organization (the client).

A business process is a set of interacting activities (working within a business organization) that create value transforming resources (considered as input of the process) in a product (the output of the process) thought for a specifc subject within or outside the organization (the client).

HSSP

• AIM: –To adopt Service Oriented

Architecture (SOA) approach to guarantee efective interoperability among applications of independent medical organizations

–To defne specifc services and to standardize their interfaces

OMG

• Is an international, open membership, not-for-proft technology standards consortium.

• Founded in 1989, OMG standards are driven by vendors, end-users, academic institutions and government agencies.

• OMG Task Forces develop enterprise integration standards for a wide range of technologies and an even wider range of industries.

• OMG’s modeling standards include the Unifed Modeling Language (UML)

HSSP• The aim of every HSSP project is the

standardization of a specifc service, which is related to a functional socio-health domain, as a generic service.

• The intention is to standardize generic functions and protocols, which allow application and technical communication, in order to invoke, accept or reject and report the performance of these functions.

HSSP•All HSSP products are distributed through the HL7 Service Functional Model (SFM) which provides a service interface specifcation at a functional level.

•Starting from the HL7 SFM, the OMG develops the “Requests for Proposal” (RFP) which are the basis of the OMG standardization process.

• In this phase vendors and other submitters propose solutions which satisfy the requirements indicated in the RFP while leaving design fexibility to the submitters and implementation fexibility to the users of the standard.

•The result of this process is the OMG Service Technical Model (STM) which specifes the technical requirements of the service.

HSSP

SOA service categories

• Healthcare-Unique Services. This category calls-out service capabilities that are either unique to healthcare, or for which healthcare has unique requirements. For instance, both record management, clinical decision support and order management appear here.

• Business Services. Business-services describe those capabilities that support business competences or processes. Some examples are terminology, payroll, accounting, human resource management and demographics.

• Technical/Infrastructure Services. These services involve capabilities like service instance location, protocol/message routing, etc.

HSSP adopted standards

• Retrieve, Locate and Update Services (RLUS) Release 1

• Common Terminology Services Release 2 (CTS2)

• Cross-Reference Service (IXS) Release 1

• Clinical Decision Support Services (CDSS) Release 1

Health Record

Management Services (HRMS)Health

Terminology Services

(HTS)Health Identity Services

(HIS)Health Decision Support Services (HDSS)

RLUS

• Provides a set of interfaces through which information systems can access and manage information within and between healthcare organizations.

• RLUS allows health data to be located, accessed and updated regardless of underlying data structures, security concerns or delivery mechanisms.

• It is independent of but compatible with underlying structures, including local security implementations, data models, or delivery mechanisms.

RLUS

• By separating and exposing those aspects of resources that facilitate inter-organization work fows in a service layer, this specifcation abstracts the problem of interoperability away from underlying systems.

• It is not intended to replace existing systems or implementations, but to create an interface standard for a service-oriented layer to expose those healthcare assets and resources within an organization that are needed to meet business or medical needs.






Health Record





CTS2

• Provides a consistent specifcation to develop service interfaces to manage, search and access terminology content, either locally, or across a federation of terminology service nodes, independent of the terminology content and underlying technological stack.

• Structured terminologies supply the basis for information interoperability by improving the efectiveness of information exchange within a specifc domain.

CTS2

• Terminological resources– Code System– Code System

Version– Entity/Concept– Map

• Functional profles– Read– Query– Export– Maintenance– History






Health Record





IXS

• Provides a set of service interfaces to uniquely identify and index various kinds of entities (patients, providers, organizations, systems and devises) both within and across health organizations.

• Allows any system which uses the service to maintain a common description for each entity and to manage the entities.

• The unique identifer and standard way to search, retrieve and manage entity data allows healthcare applications and healthcare enterprises to fnd, exchange and reference entity data while maintaining the data context and associations.






Health Record





CDSS• Provides interface specifcations and technical

requirements which are needed for a standardized approach for leveraging machine-executable medical knowledge in an application-independent manner.

• A Decision Support Services (DSS) receives patient data as the input and returns patient-specifc conclusions as the output.

• In this way, it can signifcantly facilitate the implementation of systems that require patient-specifc inference such as Clinical Decision Support (CDS) systems and quality reporting systems.

Proposed Architecture

HRMS: put/get resource

Regional EHR

Specialist

Laboratory

Patient’s Home

Hospital

Research Centre

PUT CDA R2

HRMS

HRMS: put/get resource

Regional EHR

Hospital

GET CDA R2

Specialist

General Practitioner

HRMS

HRMS: put resource

1. It processes the header → to whom the CDA R2 is addressed?

2. If can modify some XML elements: • code (clinical statement) • patient id

Laboratory

Regional EHR

HRMS

HRMS + HTS

HTSHRMS

For each code in a codesystem ≠ reference codesystem

LOINC code

HRMS + HTS + HIS

HISHRMS patient id within a specific system (root)

Patient’s Identifer

System

patient_id1 EHR

patient_id2 Research Center N.1

Regional EHR

HRMS: get resource

Hospital

HRMS

patient id

(Hospital IS)

HIS

Regional EHR patient id (EHR)

HRMS: get resource

Hospital

HRMS

patient id

(Hospital IS)

Regional EHR patient id (EHR)

HTS

HDSS and Clients

At present status

HRMS• Windows Communication

Foundation (WCF) Service• Put/get resource (RLUS)

HTS • Standard Repository • Query/search (CTS2)

HQuantum©

Some examples

Regional EHR

Patient’s Home

HRMS

CDS

Some examples

Laboratory 1 Laboratory N

HRMS HTS

Regional EHR

General Practitioner

CDA R2 + LOINC

QUESTIONS?

Acknowledge: Roberta Gazzarata

Standards & interoperability M. Giacomini DIBRIS ... · Interoperability Semantic Interoperability Technical Interoperability SO A Ability to transport data from system A ... Interoperability

Documents