osehra awg working draft rfi: not for official use. 1 osehra architecture working group (awg)...

OSEHRA AWG WORKING DRAFT RFI: not for official use. 1

OSEHRA Architecture Working Group (AWG) October 18, 2011 Telecom Open Source EHR Custodial Agent (OSEHRA) Architecture Committee

Stephen Hufnagel PhD, Chair

In collaboration withHealth Architecture Interagency Group (HAIG)

Nancy Orvis, MHA, CPHMS and Paul Tibbits, M.D., DoD and VA Co-Chairs

DRAFT OSEHRA System Architecture, SDK and companion Implementation Guide (IG) is available at: http://www.osehra.org/node/47/content/documents

EHR Modernization - System Architecture EHR Services Platform (ESP) - Software Development Kit (SDK)

CALL FOR PARTICIPATION Please post your discussion comments at http://www.osehra.org/group/architecture

OSEHRA AWG WORKING DRAFT RFI: not for official use.

DISCLAIMER

OSEHRA DRAFT WORKING DOCUMENTS ARE NOT LEGALLY BINDING

AND DO NOT REPRESENT OFFICIAL DOD OR VA POSITION.

• The DoD and VA wish to openly-and-transparently collaborate with the Open-Source EHR-Community; this is a new “agile acquisition” approach for the government and MUST evolve with lessons learned.

• The SDK, its companion Implementation Guide (IG) and related artifacts are DRAFT Working Documents, being coordinated by the Open Source EHR Custodial Agent (OSEHRA) Architecture Committee with the guidance of the DoD-VA Health Architecture Interagency Group (HAIG). The purpose is to seek EHR-modernization architectural-input from DoD & VA staff, contractors, partners, stakeholders, venders and open-source-community in an open-and-transparent collaborative-forum;

• The DRAFT Software Development Kit (SDK), its IG and any related documents MUST be considered a government Request for Information (RFI); without obligation to the government as we go through this new open-and-transparent agile-development-process;

• Once feedback has been received, OSEHRA Architecture Committee’s updates have been made and the SDK has been reviewed and approved by appropriate government leadership, DRAFT can be removed from the SDK and its IG and they will be versioned, time-stamped and an official government letter of endorsement MUST be attached.

Only an official government-endorsed-and-versioned SDK, its IG and related artifacts can be used in any government contract or acquisition process.

2


Architecture Working Group (AWG)Weekly Teleconference 2011-10-18

Every Tuesday 4:00 pm EDT https://tiag.webex.com/ +1-408-600-3600 Access code: 629 453 409 Go to https://tiag.webex.com/tiag/j.php?ED=182697922&UID=0&RT=MiMxMQ%3D%3D Please become an OSEHRA member and participate; individual membership is free.

Please join and participate in the Architecture Group. The initial 2011-baseline "OSEHRA System Architecture, Product Definition and Roadmap" working-document is posted under the Architecture-Group's Documents-tab. There is also an HTML browser viewable version. This is a living document. Please add your comments and suggestions to help us improve the architecture.

Between now and December we plan to validate the System Architecture, define a future-state architecture Software Development Kit (SDK) and then begin to define an

OSEHRA Product Roadmap. You can also add your thoughts. ideas and architectural artifacts on the OSEHR System Architecture Wiki.

3


Preface In March 2011, VA Secretary Eric Shinseki and DOD Secretary Robert Gates

agreed on a common EHR technical architecture, data and services and exchange standards for the joint EHR system, where the joint EHR will include both proprietary and open source software. The secretaries of the Veterans Affairs and Defense Departments met on May 2 and June 23, 2011 to determine their next steps toward developing a single electronic health record, for the two agencies.

“VA is developing an open source track to modernize VistA and will incorporate the approach in the joint EHR", Shinseki said. “One of my objectives is to have minimal disruption in the hospitals as we evolve from VistA to the joint EHR system What I think you will see us do is replace modules, do incremental upgrades.” … “In five or 10 years, there may not be one line of code left from VistA. And in my ideal world, the users will have no idea that I have made any changes,” VA Secretary Eric Shinseki said.

“Our goals are to bring in as many private sector modules as possible and selecting the same thing to run between VA and DOD so that we end up with a single, common electronic health record system,” Roger Baker, VA CIO said.

This presentation is the start of the journey to implement the vision expressed above.

4


Open Source Principles

Principle 1: There are more smart, creative, innovative people outside of the organization than inside

Principle 2: Software is human Knowledge Transformed into Code… It Needs Operators, Maintainers an engaged Community to Thrive

Principle 3: Closed projects die from intellectual starvation … Software is never a finished product

Principle 4: Attract Interested People … With Shared Goals … and, then Earn Their Trust!

Principle 5: Transparency, Transparency, Transparency … Remove Walls and Locked Gates to Information

Principle 6: The Community is a Meritocracy based on Autonomy, Mastery and Purpose

Principle 7: Release Early … Release Often

Principle 8: Avoid Private Discussions

Principle 9: Establish Credibility … Forge Strong Relationships with other Open Source Communities

Principle 10: Welcome the Unexpected … Contributors Will Always Surprise … Listen Carefully!

5


Open Source EHR (OSEHRA) Key Architecture Related Milestones

• 17-Jun-11 √ Contract signed

• 17-Aug-11 √ Custodial Agent Established as 501-c6 non-profit org.

• 18-Aug-11 √ VA provided the initial VistA baseline to OSEHRA

• 17-Sep-11 √ OSEHR Initial-Baseline 2011-System-Architecture

• 17-Oct-11 √ Custodial Agent Fully Operational

• 17-Dec-11 OSEHR Verified-Baseline 2011-System-Architecture

VistA Modernization Software Development Kit (SDK)

• 17-Mar-12 “Strawman” OSEHR Product Definition & Roadmap

• 17-Jun-12 “Ironman” OSEHR Product Definition & Roadmap

6


2011 VistA Architecture (Conceptual View)

7


VistA Components modeled as UML classes, showing • Component descriptions and functions• Component-to-component dependencies• Component-to-data dependencies• Links to VistA Documentation,* • Links to code,** test fixtures,** test reports,** certifications. **

AWG: Manage EHR Open Source Architecture

* The VistA Documentation Library is available at http://www.va.gov/vdl/ ** help needed to identify these artifacts

8


AWG: Manage EHR Open Source Product Definition

• Application Program Interfaces (APIs)

• Component functional-descriptions linked to VistA component UML classes

– based on HL7 EHR System Functional Model (EHR-S FM),

– Including EHR-S FM conformance criteria to support test and certification,

– Including ARRA Meaningful use objectives and criteria, mapped via EHR-S-FM,

– Including HHS mandated HITSP-constructs, mapped via EHR-S-FM,

– Including HHS/ONC EHR standards and certification criteria, mapped via EHR-S-FM.

• Interface Interconnect Agreements (IIA) & Database Interchange Agreements (DBIA) * √

• Component-level codebase-analysis conclusions-and-recommendations & Aviva prototype *

• GT.M & Cache deployment environment components & APIs modeled as UML classes

– Patch sequence order to update deployed systems (as distributed internal within VA) *

• Roadmap of configuration-baselines of product-deployment release-contents (quarterly)

9


Legend & Glossary for VistA System Architecture Model Elements and Constructs class Legend for VistA System Architecture Model Elements and Constructs

VistA Package

+ FileMan

+ API

+ File

+ ICR/DBIA

+ Module

+ Routine

+ RPC

+ Toolkit

+ FileMan (VistA's DBMS)

+ Component

+ MUMPS Global

Module

Requireded Interface (e.g., VistA API or RPC)Component

Provided Interface (e.g., VistA API or RPC)

Requireded Interface (e.g., VistA API or RPC)

Routine

API RPC

Toolkit

MUMPS Global

Boundary Namespace

File

UML Class

UML Class-2 UML Entity

ICR/DBIA

InterfaceUML Class-3

BOLD RED element border indicates incomplete or ambiguous information is available.

BOLD BLACK element border indicates an M Global Namespace or FileMan managed File

FileMan (VistA's DBMS)

Node (External)

Subsystem Lev el

Transition Lev el

Package Lev el

API or RPC call

association

generalization

dependency

1..*

has-a

realize

is-a

0..*

has-a

0..*

has-a

26k+

has-a

168

aggregation

1..*

has-a 0..*

is-a

realize

install dependency

is-a

manages

«flow»

«flow»

0..*

access

10


class OSEHR Product Definition

MS Windows

CacheDatabase Subsystem

Language Subsystem

Utility Subsystem

OSEHR

GT.M

Utility Subsystem

Language Subsystem

Database Subsystem

GNU/LINUX

VistA 1.0: Clinical

VistA 1.0: Infrastructure

VistA 1.5: HealtheVet

VistA 1.0: Administrativ e-

Financial

runs on

has-a

has-a has-a

1

runs with

0..1

1

runs with

0..1

has-ahas-a

has-a

runs on

36

has-a

12

has-a

37

has-a

81

has-a

OSEHRA/VistA Product Definition

11


2011 VistA Clinical Application Packageshttp://www.va.gov/vdl/section.asp?secid=1

1. Admission Discharge Transfer (ADT)2. Ambulatory Care Reporting3. Anticoagulation Management Tool (AMT)4. Automated Service Connected Designation (ASCD)5. Beneficiary Travel6. Blind Rehabilitation7. Care Management8. Clinical Case Registries9. Clinical Procedures10. Clinical/Health Data Repository (CHDR)11. Computerized Patient Record System (CPRS)12. CPRS: Adverse Reaction Tracking (ART)13. CPRS: Authorization Subscription Utility (ASU)14. CPRS: Clinical Reminders15. CPRS: Consult/Request Tracking16. CPRS: Health Summary17. CPRS: Problem List18. CPRS: Text Integration Utility (TIU)19. Dentistry20. Electronic Wait List21. Emergency Department Integration Software (EDIS)22. Functional Independence Measurement (FIM)23. Group Notes24. HDR - Historical (HDR-Hx)25. Home Based Primary Care (HBPC)

26. Home Telehealth27. Immunology Case Registry (ICR)28. Incomplete Records Tracking (IRT)29. Intake and Output30. Laboratory31. Laboratory: Anatomic Pathology32. Laboratory: Blood Bank33. Laboratory: Blood Bank Workarounds34. Laboratory: Electronic Data Interchange (LEDI)35. Laboratory: Emerging Pathogens Initiative (EPI)36. Laboratory: Howdy Computerized Phlebotomy Login Process37. Laboratory: National Laboratory Tests (NLT) Documents and LOINC Request Form38. Laboratory: Point of Care (POC)39. Laboratory: Universal Interface40. Laboratory: VistA Blood Establishment Computer Software (VBECS)41. Lexicon Utility42. Medicine43. Mental Health44. Methicillin Resistant Staph Aurerus (MRSA)45. Mobile Electronic Documentation (MED)46. Nationwide Health Information Network Adapter (NHIN)47. Nursing48. Nutrition and Food Service (NFS)49. Oncology50. Patient Appointment Info. Transmission (PAIT)

12


2011 VistA Clinical Application Packageshttp://www.va.gov/vdl/section.asp?secid=1

51. Patient Assessment Documentation Package (PADP) 52. Patient Care Encounter (PCE)53. Patient Record Flags54. Pharm: Automatic Replenish / Ward Stock (AR/WS)55. Pharm: Bar Code Medication Administration (BCMA)56. Pharm: Benefits Management (PBM)57. Pharm: Consolidated Mail Outpatient Pharmacy58. Pharm: Controlled Substances59. Pharm: Data Management (PDM)60. Pharm: Drug Accountability61. Pharm: Inpatient Medications62. Pharm: National Drug File (NDF)63. Pharm: Outpatient Pharmacy64. Pharm: Prescription Practices (PPP)65. Primary Care Management Module (PCMM)66. Prosthetics67. Quality Audiology and Speech Analysis and Reporting (QUASAR)68. Radiology / Nuclear Medicine69. RAI/MDS70. Remote Order Entry System (ROES)71. Scheduling72. Shift Handoff Tool73. Social Work74. Spinal Cord Dysfunction75. Standards & Terminology Services (STS)

76. Surgery77. VistA Imaging System78. VistAWeb79. Visual Impairment Service Team (VIST)80. Vitals / Measurements81. Womens’ Health

13


2011 VistA Infrastructure Application Packageshttp://www.va.gov/vdl/section.asp?secid=2

1. Capacity Management Tools2. Duplicate Record Merge: Patient Merge3. Electronic Error and Enhancement Reporting (E3R)4. Enterprise Exception Log Service (EELS)5. FatKAAT6. FileMan7. FileMan Delphi Components (FMDC)8. Health Data Informatics9. HL7 (VistA Messaging)10. Institution File Redesign (IFR)11. KAAJEE12. Kernel13. Kernel Delphi Components (KDC)14. Kernel Toolkit15. Kernel Unwinder16. List Manager17. MailMan18. Master Patient Index (MPI)19. Medical Domain Web Services (MDWS)20. M-to-M Broker21. Name Standardization22. National Online Information Sharing (NOIS)23. National Patch Module24. Network Health Exchange (NHE)25. Patient Data Exchange (PDX)

26. Remote Procedure Call (RPC) Broker27. Resource Usage Monitor28. Single Signon/User Context (SSO/UC)29. SlotMaster (Kernel ZSLOT)30. SQL Interface (SQLI)31. Standard Files and Tables32. Statistical Analysis of Global Growth (SAGG)33. Survey Generator34. System Toolkit (STK)35. VistA Data Extraction Framework (VDEF)36. VistALink37. XML Parser (VistA)

14


2011 VistA Financial-Administrative Application Packageshttp://www.va.gov/vdl/section.asp?secid=3

1. Accounts Receivable (AR)2. Auto Safety Incident Surv Track System (ASISTS)3. Automated Information Collection System (AICS)4. Automated Medical Information Exchange (AMIE)5. Clinical Monitoring System6. Compensation Pension Records Interchange (CAPRI)7. Current Procedural Terminology (CPT)8. Decision Support System (DSS) Extracts9. Diagnostic Related Group (DRG) Grouper10. Electronic Claims Management Engine (ECME)11. Engineering (AEMS / MERS)12. Enrollment Application System13. Equipment / Turn-In Request14. Event Capture15. Fee Basis16. Fugitive Felon Program (FFP)17. Generic Code Sheet (GCS)18. Health Eligibility Center (HEC)19. Hospital Inquiry (HINQ)20. ICD-9-CM21. IFCAP22. Incident Reporting23. Income Verification Match (IVM)24. Integrated Billing (IB)25. Integrated Patient Funds

26. Library27. Occurrence Screen28. Patient Representative29. Personnel and Accounting Integrated Data (PAID)30. Police and Security31. Quality Management Integration Module32. Record Tracking33. Release of Information (ROI) Manager34. Veterans Identification Card (VIC/PICS)35. Voluntary Service System (VSS)36. Wounded Injured and Ill Warriors

15


2011 VistA HealtheVet Application Packageshttp://www.va.gov/vdl/section.asp?secid=4

1. Clinical Information Support System (CISS)2. Electronic Signature (ESig)3. HealtheVet Web Services Client (HWSC)4. My HealtheVet5. National Utilization Management Integration (NUMI)6. Occupational Health Record-keeping System (OHRS)7. Patient Advocate Tracking System (PATS)8. Person Services9. Registries10. Spinal Cord Injury and Disorders Outcomes (SCIDO)11. VA Enrollment System (VES)12. Veterans Personal Finance System (VPFS)

16

OSEHRA AWG WORKING DRAFT RFI: not for official use. 17

Suggested Plan of Actions and Milestones (POA&M) toRefactor & Certify Legacy MUMPS within ESP Enabled System1. CY2011: Verified System Architecture, Product Baseline and Roadmap

2. CY2012: Prepare

• Complete ESP SDK through Open-Source-Community & DoD, VA, IHS collaboration • Specify future-state ESP Key Performance Parameters (KPPs) and implementation constraints• Get ESP SDK officially endorsed by DoD and VA leadership; work ESP SDK through HL7, OASIS & OMG SDOs• Specify OSEHR automated ESP enabled system certification-test-scripts & Built-in-Test-Environment (BITE)• Proof-of-concept refactoring-prototype (e.g., scheduling, clinical & nursing notes modules) • ESP enabled system & test environment prototype in a Virtual Machine (VM)

3. CY2013: Build Critical Components

• Construct automated-certification test-scripts for ESP & key applications• Construct ESP Built-in-Test-Environment (BITE)• Construct ESP reference-implementation in a VM test environment• Refactor & certify VistA Kernel & FileMan into as ESP enabled system

4. CY2014: Build Necessary Components

• Refactor & certify strategically important applications to be ESP conformant.• Refactor & certify other modules/routines in MUMPS to use ESP SDK specified services

5. CY2015: Integrate and Make Everything Work to Users Satisfaction

• ESP Integrate & certify other-available critical-components ESP (e.g., VLER, pharmacy, lab, imaging) • Performance optimize ESP & integrated applications to meet KPPs

17


Suggested OSEHRA Role in MUMPS Code Refactoring

1. Thought Leadership

2. OSEHR System Architecture, Product Definition and Roadmap

3. Technical, Operational and Functional Certification

4. Open Source Tools, Test & Collaboration Environment Management

5. Configuration Management of:

1. OSEHR Services Platform (ESP) Software Development Kit (SDK)

2. Codebase

3. Certification test artifacts (fixtures, results, attestations)

6. Technical/ Standards Mentoring, Verification and Validation of:

1. Refactoring

2. ESP system enablement (Refactored VistA Kernel & Fileman Modules)

3. Automated Certification test scripts, fixtures & Built-in-Test-Environment (BITE)

4. Operational/technical/functional testing and certification

7. Open Source Community Engagement and Professional Organizations Evangelism

18


Great Impact on links between components (e.g., interoperability)

Little Impact on links between components(e.g., Interoperability)

Little impact on components

Great impact on components

Architectural

Innovation

Radical Innovation

Incremental

Innovation

Modular Innovation

Year 1End

Archite

ctural

Visio

n for

Seman

tic Int

erope

rability

Start

Future State Architecture GOAL

OBJECTIVEA change-immune domain-specific

component-architecture emphasizing interoperable standards-based services,

resulting-in simpler, loosely-coupled, and less-costly module-level innovation.

PROBLEMLittle innovation, long lead

times and high costs resulting from complex

highly-coupled components

19


Future State Architecture Legacy- VistA Problems Being Addressed

1. Innovation to revitalize VistA

2. Interoperability among DoD, VA, IHS and purchased care partners• Heterogeneous legacy-implementation schemas, terminology & tools

3. Transition from legacy systems and data to a future-state-architecture

4. Agility to respond to rapid healthcare change and related legislation• ICD 9 ICD 10

• ARRA Meaningful Use Objectives and criteria Stages I, II, III

• HHS Mandated HITSP-constructs and HHS mandated standards

5. High Costs of change and sustainment. • Separate DoD and VA systems

• Semantic Interoperability among trading partners (e.g., consults and transfers-of-care)

• Application acquisition or development

• Commercial Off the Shelf (COTS) Integration

• Sustainment

• Test and certification

6. Patient Safety issues resulting from software changes.

7. Open Source Community Enablement 20


Software Product Certification Criteria: Safe, Compliant and Functional (1/3)

Certification is the attestation and ultimately verification that the code is:

1. Safe: For the purposes of the certification process, code is safe when the individual code units do not cause errors in other components of the system and the code is robust to all code paths-and-conditions. We will certify code as safe using a combination of:

– Regression Testing

– Test that each routine/function correctly performs operations

– Stress Testing

– Test the robustness of the system under all code pathways (exception handling)

Bold Blue indicates “supported by Architecture”

21



Certification is the attestation and ultimately verification that the code is: 2. Compliant: For the purposes of the certification process, code is compliant when it meets the agreed

upon code contract and is adherent to all applicable external laws and regulations. We will certify code as compliant using a combination of:

– Architectural Verification – architecture has been defined and the actual code is consistent– defined community standards and conventions (SAC)– Module-to module dependencies– Module-to-data dependencies

– Interoperability Testing– Test that all module APIs are defined and met

– Section 508 Testing– Test that the User Interface is compliant with section 508 of the Rehabilitation Act

– Governance Compliance Testing– Software Development Kit (SDK), Community Standards and Conventions (SAC), Licenses

– Privacy Protections and Systems Security– Test that privacy and security requirements are defined and met

Bold Blue indicates

“supported by Architecture”

22



Certification is the attestation and ultimately verification that the code is:

3. Functional: For the purposes of the certification process, code is functional when it has a defined set of requirements; when its execution satisfies the defined requirements; when execution occurs within an acceptable performance window; and when it satisfies a customer need. We will certify code as functional using a combination of:

– Confirm that requirements have been defined and met

– Map functionality to test conformance criteria

– Performance Testing

– Verification that the system meets its key performance (speed, availability) specifications

– Customer Satisfaction is validation testing which is not part of the certification process; but, it will be monitored as part of the Community Engagement function and will be presented using the certification dashboard.

Bold Blue indicates “supported by Architecture”

23


Technical Vision: EHR Service Platform (ESP)

INTEGRATED EHR SOLUTION

EHR SERVICES PLATFORM (ESP)

EHR ViewersPoint of Service

ApplicationsPersonal Health Record Systems

EHR ISLocator

Information Access & Longitudinal Record Services (LRS)

EHR Information Services (EHR IS)

EHRData &

Services

RegistriesData &

Services

Population HealthData &

Services


Services

24


TALKING POINTS: Technical Vision is to modernize and transition legacy to an EHR Services Platform (ESP) for Application Integration

• An EHR Services Platform (ESP) facilitates application innovation; it is composed of separated operation, business-rule and information services to integrate plug-&-play applications; the ESP services MUST be used by ALL applications and ALL applications MUST be service-based.

• As the ESP is fully-specified in the SDK Implementation Guide (IG), as standardized and reference implementations become available; then, general-purpose and domain-specific “best-of-class” certified applications can be user-selectable and evolve on a Darwinian basis. This is analogous to a Smart-Phone Application-Markets

• Anyone can build and submit ESP services and/or applications for certification• The Open Source EHR Custodial Agent (OSEHRA) will IV&V and CM certified ESP

application services and reference-implementations (e.g., gold builds).• DoD, VA, IHS and others may pick-&-choose, which certified applications they use.• Legacy-systems and ESP enabled systems can co-exist during long legacy transition

periods across large enterprises. This is analogous to the PC and telecommunications evolution-revolution from the 1980s to now.

25


Key Concepts: Federated EHR Services Platform



EHR ViewersPoint of Service

ApplicationsPersonal Health Record Systems

EHR ISLocator



EHRData &

Services

RegistriesData &

Services

EHR IS

EHR IS Enabled Legacy System

ESP Based SystemPopulation

HealthData &

Services

EHR IS Enabled PHR System

Tier 1Plug-&-PlayApplications

Tier 2EHR

Information Services

Tier 3Plug-&-PlayData Stores

ApplicationServices Layer

Data AccessServices Layer

EHR IP

EAI IP

EHR IPEHR IP

IP is SOA Interoperability Profile aka Service Interface

EAI is Enterprise Application Integration


Services

26


TALKING POINTS: BenefitsThe ESP can become the National and possible International EHR standard for “best-of-breed” Darwinian innovation, evolution or

revolution where anyone can participate.

The SDK’s Standards-Based Best-Practices ensure consistency across:

– Interoperable Application Service APIs• Common/ Engineering Service Bus (C/ESB)• Interoperable Plug-and-Play Applications

– Interoperable Virtual Database (DB) APIs scalable from• Legacy MUMPS-globals acting as a DB to MS Access, Open or MS SQL, Oracle to• Massively-parallel high-performance grids running on commodity-hardware-blade-platforms

(i.e., amazon.com & google.com models).

– ESP enabled Trading Partners

– Acquisitions (ESP SDK-IG as GFI for RFIs and RFPs)

– VA, DoD and IHS offices, staff and contractors

– Open Source and vender community

27


Legacy Transition Strategy

LEGACY EHR SYSTEM

EHR-IS ENABLED LEGACY INFRASTRUCTURE

LegacyPoint of Service

Application



EHR ViewerPoint of Service

Application

Personal Health Record

Systems


Services

DataWarehouse

Data & Services

EHRData &

Services

RegistriesData &

Services



DataWarehouse

Data & Services



Personal Health Record

System

EHRData &

Services

EAI IP


IP is SOA Interoperability Profile aka Service InterfaceEHR-IS enabled legacy systems allow users to transition at a convenient time and then legacy

systems can be gracefully shut down.

EHR IP

EAI IP

EHR IPEHR IP

Legacy

EHR-ISEHR-IS

Bi-Directional Information Exchange

EAI IP

28


TALKING POINTS: Transition Strategy based on ESP enabled systems1. ESP kernel-services and data stores CAN be set-up at one-or-more data-centers (any cloud topology). 2. For pre-certification self-testing and attestation, venders and developers MUST be provided: i) SDK-IG,

ii) an open-source test virtual-machine (VM) with the ESP set-of operating-and-data services, iii) clinically-meaningful test-database, test-scripts, certification-criteria.

A. Agile SDK, ESP and application development and certification processes MUST have up-to-date VMs and ongoing regression testing to obtain/maintain “certified” status.

B. Certified applications, test and certification VMs, test fixtures/scripts, test-results MUST be made available to anyone (e.g., open source community) to verify and validate test results & attestations.

3. One-or-more user-configurable ESP enabled viewers SHOULD be made freely available. 4. Legacy systems MUST be updated i) to “journal” their clinically-relevant data-store transactions with the

ESP data-store and to query via the ESP, analogous to legacy “BHIE” DoD-VA sharing; 5. Terminology mapping SHOULD be a part of legacy-data transition.6. To be repurposed to ESP capability, legacy-applications MUST conform to ESP SDK-IG and associated

certification criteria. 7. Once certified ESP enabled viewer(s) and ESP enabled applications are available to clinical users, they

CAN transition to modernized ESP based systems, while others might continue on legacy systems. 8. Clinically-meaningful legacy-data MUST be extracted to ESP before legacy systems are shut down.

29

OSEHRA AWG WORKING DRAFT RFI: not for official use.30

EHR Information Services (EHR IS) and Common Information Integration Framework (CIIF) within EHR Services Platform (ESP)


Population Health Data& Services

Registries Data& Services

EHR Data& Services

Data Warehouse

& Services

OutbreakManagement

PHSReporting

SharedHealth Record

DrugInformation

DiagnosticImaging

LaboratoryHealth

Information

POINT OF SERVICE APPLICATIONS

Hospital, LTC,CCC, EPR

PhysicianOffice EMR

EHR Viewer

Physician/Provider

BusinessRules

EHRIndex

MessageStructures

NormalizationRules

Security MgmtRules/Data

Privacy Mgmt Rules/Data

Configuration Rules/Data

Physician/Provider

Physician/Provider

Lab System(LIS)

Lab Clinician

RadiologyCenter

PACS/RIS

Radiologist

PharmacySystem

Pharmacist

Public HealthServices

Public Health Provider


EHR ISSecure Communications Bus

Common Information Integration Framework (CIIF) and Common Services

ClientRegistry

ProviderRegistry

LocationRegistry

TerminologyRegistry

ORGANISATIONAL INFOSTRUCTURE

EHR IPEHR IPEHR IPEHR IPEHR IP EHR IP EHR IP

EAI IPEAI IP

IP is SOA Interoperability Profile aka Service Interface



TALKING POINTS: Common Information Integration Framework (CIIF)

• The Common Information Integration Framework (CIIF) is a business-driven agile enterprise-information-management methodology and set of software-service technologies, which enable semantic interoperability of clinical data.

• The CIIF Team specifies or imposes a standards-based set of information services that enables any authorized empowered provider to care for any beneficiary regardless of location, organization or device.

31

OSEHRA AWG WORKING DRAFT RFI: not for official use.32

ERH Services Platform (ESP) enabled system (conceptual view)


1. Innovation to revitalize VistA. • Services within a standards-based component-architecture encourage lower-cost component innovation without

requiring enterprise-wide expertise and extensive testing. SDK empowers individuals and avoids stovepipes. 2. Interoperability among DoD, VA, IHS and purchased care partners.

• CIIF canonical information and terminology models can be used to map among heterogeneous system information exchanges. By adopting common CIIF data, terminology, and communications standards; multiple organizations can share and ultimately harmonize Electronic Medical Records.

3. Transition from legacy systems and data to an interoperable EHR architecture.• Virtualization-Layers of Federated Standards-Based Services allow new and legacy COTS, GOTS and open-

source applications, scaleable databases and infrastructure to coexist. 4. Agility to respond to rapid healthcare changes and related legislation.

• Services within a standards-based component-architecture encourage faster and lower-cost changes to be made and tested within components without requiring enterprise-wide expertise and testing.

5. High Costs of change and sustainment. • Virtualization-Layers of Federated Standards-Based Services make plug-and-play applications, databases and

infrastructure possible, which can be treated as commodities and can be tested efficiently. Interchangeable-components can compete based, on functionality, quality, performance vs. cost, usability and supportability. Built In Test Environment (BITE) identifies faults early, improving robustness and reducing test costs. .

6. Patient Safety issues resulting from software changes.• Component architecture localizes faults. BITE identifies faults early, improving system robustness, patient safety.

7. Open Source Community Enablement• Virtualization-Layers of Federated Standards-Based Services support alternate configurations of applications,

databases and infrastructure, which may be combinations of MUMPS, COTS, GOTS and open source code to meet the specific-needs of various stakeholder-and-user communities.

Future State Architecture Addressing Legacy-VistA Problems

33


SystemArchitecture

ArchitecturalBehavioralViewpoints

Conceptual Independent ModelPlatform Independent Model

Platform Specific Model

ArchitecturalInformation Viewpoints

Conceptual Independent ModelPlatform Independent Model

Platform Specific Model

ArchitecturalEngineering/

TechnicalViewpointsConceptual Independent Model

Platform Independent ModelPlatform Specific Model

CUIs

CUIsCUIs

CUIs

ArchitecturalBusiness

ViewpointsConceptual Independent Model


Key to Traceability Traceability is achieved by using Concept Unique (numeric) Identifiers (CUIs) from the HL7 EHR System Functional Model (EHR-S FM)

as attributes to all artifacts. This is analogous to a library system, which uses Dewey decimal numbers as book identifiers.

Core ProjectsPlan for New, Improved, Sustained or Sunset

Capabilities

Product Line Inventory

Inventory of Systems and their Capabilities and Functions

CUIsCUIs

Approach to Architectural Traceability

Innovation/ Prototype ProjectsConceptual Independent Model


CUIs

Interoperability ProjectsConceptual Independent Model


CUIs

34


HL7 Service Aware Interoperability Framework (SAIF)Enterprise Compliance and Conformance Framework (ECCF)

Inventory of• User Cases, Contracts• Capabilities Business Mission,

Vision, Scope

Inventory of• User Cases, Contracts• Capabilities Business Mission,

Vision, Scope

Enterprise Dimension“Why” - Policy

Enterprise Dimension“Why” - Policy

Business Policies Governance Implementation Guides Design Constraints Organization Contracts

Business Policies Governance Implementation Guides Design Constraints Organization Contracts

Business NodesBusiness RulesBusiness ProceduresBusiness WorkflowsTechnology Specific

Standards

Business NodesBusiness RulesBusiness ProceduresBusiness WorkflowsTechnology Specific

Standards

Inventory of• Domain Entities • Activities• Associations• Information

Requirements• Information Modelso Conceptualo Domain

Inventory of• Domain Entities • Activities• Associations• Information

Requirements• Information Modelso Conceptualo Domain

Information Dimension

“What” - Content

Information Dimension

“What” - Content

Information Models Terminologies Value Sets Content Specifications

Information Models Terminologies Value Sets Content Specifications

Schemas for• Databases• Messages• Documents• Services• Transformations

Schemas for• Databases• Messages• Documents• Services• Transformations

Inventory of• Functions-services Requirements• Accountability, Roles• Functional

Requirements, Profiles, Behaviors, Interactions

• Interfaces, Contracts

Inventory of• Functions-services Requirements• Accountability, Roles• Functional

Requirements, Profiles, Behaviors, Interactions

• Interfaces, Contracts

Computational Dimension

“How” - Behavior

Computational Dimension

“How” - Behavior

Specifications• Use Cases, Interactions• Components, Interfaces

Collaboration Participations

Collaboration Types & Roles

Function Types Interface Types Service Contracts

Specifications• Use Cases, Interactions• Components, Interfaces

Collaboration Participations

Collaboration Types & Roles

Function Types Interface Types Service Contracts

Automation UnitsTechnical InterfacesTechnical OperationsOrchestration Scripts

Automation UnitsTechnical InterfacesTechnical OperationsOrchestration Scripts

Inventory of• SW Platforms, Layers• SW Environments• SW Components• SW Services• Technical

Requirements• Enterprise Service Bus Key Performance

Parameters

Inventory of• SW Platforms, Layers• SW Environments• SW Components• SW Services• Technical

Requirements• Enterprise Service Bus Key Performance

Parameters

Engineering Dimension

“Where” - Implementation

Engineering Dimension

“Where” - Implementation

Models, Capabilities, Features and Versions for• SW Environments• SW Capabilities• SW Libraries• SW Services• SW Transports

Models, Capabilities, Features and Versions for• SW Environments• SW Capabilities• SW Libraries• SW Services• SW Transports

SW Specifications for• Applications• GUIs• Components

SW Deployment Topologies

SW Specifications for• Applications• GUIs• Components

SW Deployment Topologies

Inventory of• HW Platforms• HW Environments• Network Devices• Communication

Devices Technical

Requirements

Inventory of• HW Platforms• HW Environments• Network Devices• Communication

Devices Technical

Requirements

Technical Dimension

“Where” - Deployments

Technical Dimension

“Where” - Deployments

Models, Capabilities, Features and Versions for• HW Platforms• HW Environments• Network Devices• Communication

Devices

Models, Capabilities, Features and Versions for• HW Platforms• HW Environments• Network Devices• Communication

Devices

HW Deployment Specifications

HW Execution ContextHW Application BindingsHW Deployment TopologyHW Platform Bindings

HW Deployment Specifications

HW Execution ContextHW Application BindingsHW Deployment TopologyHW Platform Bindings

Conceptual PerspectiveConceptual Perspective

ECCFECCF

Logical Perspective

Logical Perspective

Implementable Perspective

Implementable Perspective

35


TALKING POINTS: HL7 Service Aware Interoperability Framework (SAIF) Conformant ESP Implementation Guide (IG)

• To be OSEHRA software-quality certified, ESP enabled applications MUST be conformant to the companion ESP SDK Implementation Guide (IG) which follows HL7 SAIF guidance.

– The SDK slide set is the SAIF Conceptual Perspective– The SDK Implementation Guide is the SAIF Logical Perspective– Developers & Venders MUST deliver the SAIF Physical Perspective

• SAIF provides guidance; but, OSEHRA, DoD, VA, IHS and stakeholders MUST establish a consensus ESP IG, defining required architectural views (e.g., subset of DoDAF views) and appropriate specification language (e.g., BPMN, UML).

• The ESP companion SDK IG is HL7 SAIF conformant and defines software-engineering best-practices for interoperability Standards and Conventions (iSAC).

• Agile processes are being followed to define the SDK slides and IG; that is, there will be many incremental refinements.

36


Future-State Architecture Software Development Kit (SDK)Draft Specifications needed by Fall 2011 *

1. Built-In-Test-Environment (BITE) Service Specification to support automated fault-detection resulting from distributed ad-hoc partners & plug-and-play applications. • Model-Driven Health-Tool defines run-time schematron test fixtures.• Performance-Monitoring-Component Service-Specification to trace run-

time execution pathways and measure latency to support, system tuning, automated testing and certification.

• Code-Coverage Regression-Test and Stress-Test Tool-Specification, to support automated testing and certification of “happy path” and fault recovery pathways.

• Cross-Reference Tool-Specification to automatically map module-module and module-data dependencies and certify no unexpected changes.

• Pretty-Printer Tool-Specification to certify software-module Standards and Conventions (SAC) & to do syntax verification and readability reformatting.

37


Future-State Architecture Software Development Kit (SDK)Draft Specifications needed by Fall 2011 *

2. SAIF ECCF Implementation Guide (IG) for documenting component Interoperability Specifications, which will support new development, repurposing, reimplementation, automated testing and certification.

• ESB Services Specification of iEHR Tier 1-2 Application Virtualization-Layer of federated standards-based services.

• Database Services Specification of iEHR Tier 2-3 Database Virtualization-Layer of federated standards-based services.

3. SAIF ECCF Tool Specification to manage module Interoperability Specifications, which will support new development, repurposing, reimplementation, automated testing and certification.

4. Standards and Conventions (SAC), updated to modern SOA software engineering practices, as defined by Thomas Erl.

38


NIST 7497 Security Architecture * Design Principles

1. Perform Information Assurance Risk assessments of shared information;

2. Create “master” trust agreements describing requirements for a trust domain;

3. Separate authentication/credential management and authorization/privilege management;

4. Develop data protection capabilities as plug-and-play services;

5. Maintain a standards-based, technology-neutral, and vendor-neutral architecture.

* NIST IR 7497, Security Architecture Design Process for Health Information Exchanges (HIEs) , Sept. 2010, available at http://csrc.nist.gov/publications/PubsNISTIRs.html

39


NIST 7497 Security ArchitectureEnabling Services

1. Risk Assessment is a Security and Privacy Principles, which means to identify security and privacy risks to HIE operations based on threats, assets, vulnerabilities, and likelihood of threat success.

2. Entity Identity Assertion (Authentication) is HITSP Construct * SC110 & C19, which ensures that an entity is the person or application that claims the identity provided.

3. Credential Management is a Security Principles, which means to manage the life cycle of entity credentials used for authentication and authorization.

4. Access Control (Authorization) is HITSP Construct * SC108 & TP20, which ensures that an entity can access protected resources if they are permitted to do so.

5. Privilege Management is a Security Principles, which means to manage the life cycle of an entity’s authorization attributes (e.g., roles, permissions, rules) for making access control decisions.

6. Collect and Communicate Audit Trail is HITSP Construct * SC109 & T15, which defines and identifies security-relevant events and the data to be collected and communicated as determined by policy, regulation, or risk analysis.

40


NIST 7497 Security ArchitectureEnabling Services

7. Document Integrity is HITSP Construct * T31, which validates that the contents of a document have not been changed in an unauthorized or inappropriate manner.

8. Secured Communication Channel is HITSP Construct * SC109 & SC112, which ensures that the mechanism through which information is shared or transmitted appropriately protects the authenticity, integrity, and confidentiality of transactions to preserve mutual trust between communicating parties.

9. Document Confidentiality is a Security Principles, which means to prevent the unauthorized disclosure of a document that is exchanged or shared.

10. De-identification is a Privacy Principles, which means to remove individual identifiers from a health record, or replace them with other information such as pseudonyms, so that it cannot be used to identify an individual.

11. Non-Repudiation of Origin is HITSP Construct * C26, which provides the proof of the integrity and origin of data in an unforgettable relationship which can be verified by any party.

12. Manage Consent Directives is HITSP Construct * TP30, which ensures that individually identifiable health information is accessed only with an individual’s consent.

41


NIST 7407 Security Architecture

Web-Service Security-Standards

42


NIST 7497 Security ArchitectureNotional Development Process

43


PROVIDERS’ EHR DATA REUSEACROSS EPISODES OF CARE

• Patient Demographics• Provider Demographics• Insurer Demographic

IDENTITY

Terminology

Document

• Chronic Diagnoses• Procedure History

• Patient History• Summary Lists - Medication List - Allergy/Adverse Reaction List - Immunization

Current EpisodeOf Care EHR

Previous EpisodeOf Care EHR

Reu

sabl

e S

ervi

ces

Data Must Be Verified And Updated

44


Case-Managers’ EHR Data ReuseAcross the Continuum of Care

ASSESSMENTCARE

PLANNING

ORDERS &

SCHEDULING

BENEFITMANAGEMENT

AUTHORIZATION &

UTILIZATION MGT.

COMMUNICATION(FACILITATION

ADVOCACY)

DISCHARGE/TRANSFERPLANNING

REFERRAL RECORD TRANSPORT

ROLE OF CASE MANAGER

AcuteInpatient

ChronicRehab.

OutpatientWartimeTheater

ER AcuteRehab.

SkilledLongTerm Care

CustodialLongTermCare

HomeHealth

Prevention/Wellness

Care Continuum

Coordination ACROSS SOAS

cCOORDINATION ` ACROSS LEVELS OF CARE, PROVIDERS and LOCATIONS

EDUCATION.

45


HL7 EHR System Functional Model (EHR-S)(> 230 System Functions in 4 level categorization

(see attached spreadsheet for full enumeration)

NOTE: “Other” Category - The EHR-S model does NOT include Electronic Resource Planning (ERP) / Logistics and Financial components, which are needed for completeness of a military EHR.

Other O-1 Electronic Resource Planning (ERP)

O-2 Finances

O-3 Other

Business

Entity(Information)

Choreography

Infrastructure

Choreography

Business

Business

Infrastructure

Infrastructure

Infrastructure

Entity(Information)

Ser

vice

Typ

es

Sys

tem

Fun

ctio

ns

Choreography

Business

04/18/23


Ap

plic

atio

n la

yer

Se

rvic

es

inte

rfa

ce la

yer

Bu

sin

ess

p

roce

ss la

yer

SOA LayersFocus on the Business Processes and Services [Thomas Erl]

Source: Service-Oriented Architecture, Thomas Erl

orchestration service layer

business service layer

application service layer

SystemComponentsand Services

Business Capabilities and Services

47


SOA Service ModelsPotential Service Layers [Thomas Erl]

Service Model DescriptionApplication Service

A generic category used to represent services that contain logic derived from a solution or technical platform. Services are generally distinguished as application services when creating abstraction layers.

Business Service

A generic category used to represent services that contain business logic. When establishing specialized service layers, services that fall into the business service layers are collectively referred to as business. However, individually these services are classified as entity-centric (e.g., information) or task-centric business services.

Controller Service

A Service that composes others. Variations of this model exist, depending on the position of the controller in the composition hierarchy. The patent controller service can be classified as the master controller and a service that composes a subset of a larger composition can be labeled as sub-controller.

Coordinator Services

Three service models are derived from the concept of coordination: the coordinator, the atomic transaction coordinator, and the business activity coordinator. All three models are specific to the WS-Coordination specification and related protocols.

Entity-centric Business Service

A business process-agnostic variation of the business service that represents one or more related business entities. This type of service is created when establishing a business service layer.

Hybrid Service

A service that contains both business and application logic. Most services created as part of traditional distributed solutions fall into this category. When organizing services into abstraction layers, hybrid services are considered part of the application service layer.

Integration Service

An application service that also acts as an endpoint to a solution for cross-referencing integration purposes.

Process Service

A service that represents a business process as implemented by an orchestration platform and described by a process definition. Process services reside in the orchestration service layer.

Task-Centric Business Service

A business process-specific variation of the business service that represents an atomic unit of process logic. Task-centric services are different from process services in that the process logic is provided by the underlying service logic, not by a separate process definition.

48


Healthcare SOA Reference Architecture (H-SOA-RA)Based on HL7 EHR System Functional Model & Thomas Erl’s SOA Layers

HL7 System Functions

Direct Care Supportive Information Infrastructure

Other

Business Process

Value Chains

CompositeServices Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas

Core BusinessServices

Functional Areas + Focal Classes




EntityServices

Information Management



Information Reporting and Management

Agnostic Services

C r o s s T e c h n I c a l “Common S e r v I c e s”(e.g., Security, Privacy, Auditing, Logging…)

ApplicationServices

Ambulatory Care Systems,

In Patient Care Systems

Logistics SystemsFinancial Systems

Decision Support Systems

Data MartsRepositories

Business Objects

ImplementationProfiles

Integrated Healthcare Enterprise (IHE) Profiles

Analysis Profiles Communications Profiles/Stacks

Implementation Profiles

49


SUPPLY CHAIN (ORDER/CHARGE)

ANATOMY OF AN ANCILLARY SYSTEM

AUTHORIZATION

DOCUMENT

RECORDS MANAGEMENT

DECISION SUPPORT

PERFORMANCE

DATA MANAGEMENT

SCHEDULING

IDENTITY

TERMINOLOGY

LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH

s

EN

AB

LIN

G B

US

INE

SS

SE

RV

ICE

S

50

OSEHRA AWG WORKING DRAFT RFI: not for official use.IT PLATFORM

SUPPORT

ANALYTIC

DATA MANAGEMENT

PERFORMANCE

DECISION SUPPORT

RECORDS MANAGEMENT

DOCUMENT

SUPPLY CHAIN: (ORDERS/CHARGES)

SCHEDULING

AUTHORIZATION

TERMINOLOGY

IDENTITY

RADIOLO

GY

LABORATO

RY PHARMACY

CLI

NIC

AS

U

T

ES

T O

NLY

O

UT

PA

TIE

NT

OT

HE

R

INP

AT

IEN

T E

R

CARDIOLO

GY

PT/O

T/SPEECH

DIETARY

SPECIALTY CARE

Ancillary Systems

En

abli

ng

Bu

sin

ess

Ser

vice

sINTEGRATED

REQUIREMENTSDESIGNS: Putting the H-SOA-RA

Pieces Together

RESPIRAT

ORY

Fed

erat

ed B

usi

nes

sS

ervi

ces

Ag

no

stic

S

ervi

ces

Federated Services, may be categorized by: -- Encounter Types -- CMS billing category -- Record type -- Care setting type -- etc.

Data sets are defined for each system functional-

capability-service module 51In

ter-

Age

ncy

Inte

r-S

ervi

ceA

cros

sP

rovi

ders


Addressing Real Business Issues Through H-SOA-RA based Integrated Requirements-Design

• Incomplete/Inaccurate Demographic Data (Identity Service)• Incomplete/Inaccurate Insurance Information (Authorization Service)• Unauthorized Service (Authorization Service)• Diagnosis/Procedure Coding Errors (Terminology Service)• Service Delays (Scheduling Service)• Incomplete and Inefficient Charge Capture (Supply Chain Service)• Non-indicated or Contra-indicated Services (Decision Support/

Authorization Services)

• Delays in EHR Document Production and Provision (Document Service)• Billing Delays and Errors (Supply Chain/ Billing/ Collection Services)• Not fully coordinated Scheduling (Scheduling Service) • Lack of fully integrated Patient Assessment and Treatment Plan (Document Service/ Decision Support Service)• Delayed or Lack of Medical Record Access (Record Service)

52


Contact Informationand Initial Plan

• tiag® is the prime contractor. tiag® is an SBA certified 8(a) woman-owned, small disadvantaged business. Corporate Headquarters: (703) 437-7878 • 1760 Reston Pkwy Suite 510, Reston, VA 20190

• Seong K. Mun, PhD of Virginia Tech serves as the acting Senior Program Coordinator of the CA. He can be reached at 'Mun, Seong Ki' ([email protected])

• OSEHR Inc. will be an independent not-for-profit organization.

• Open source EHR custodial agent (OSEHRA) milestones: • 17-Aug-11: incorporated as a 501-c6 Non-Profit Org.

• 17 Sep-11: Deliver System Architecture and Product Definition

• 17-Oct-11: fully operational

• Additional information is available at www.OSEHRA.org

53