Transcript Infoway Boiler Plate

CALL FOR PARTICIPATION
Please post your discussion comments at
http://www.osehra.org/group/architecture
EHR Modernization
EHR Services Platform (ESP)
System Architecture
- Software Development Kit (SDK)
OSEHRA Architecture Working Group (AWG) October 18, 2011 Telecom
Open Source EHR Custodial Agent (OSEHRA) Architecture Committee
Stephen Hufnagel PhD, Chair
In collaboration with
Health 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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
1
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
2011 VistA
Architecture (Conceptual View)
7
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
AWG: Manage EHR Open Source Architecture
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. **
* The VistA Documentation Library is available at http://www.va.gov/vdl/
** help needed to identify these artifacts
8
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Legend & Glossary for VistA System Architecture Model Elements and Constructs
10
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
OSEHRA/VistA Product Definition
class OSEHR Product Definition
VistA 1.0:
Clinical
OSEHR
VistA 1.0:
Infrastructure
has-a
has-a
37
81
1
1
has-a
VistA 1.5:
HealtheVet
Database
Subsystem
has-a
12
runs with
Cache
36
runs with
0..1
0..1
has-a
GT.M
has-a
has-a
has-a
Language
Subsystem
Database
Subsystem
has-a
has-a
Utility
Subsystem
VistA 1.0:
Administrativ eFinancial
Language
Subsystem
Utility
Subsystem
runs on
runs on
MS Window s
GNU/LINUX
11
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
2011 VistA Clinical Application Packages
http://www.va.gov/vdl/section.asp?secid=1
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
Admission Discharge Transfer (ADT)
Ambulatory Care Reporting
Anticoagulation Management Tool (AMT)
Automated Service Connected Designation (ASCD)
Beneficiary Travel
Blind Rehabilitation
Care Management
Clinical Case Registries
Clinical Procedures
Clinical/Health Data Repository (CHDR)
Computerized Patient Record System (CPRS)
CPRS: Adverse Reaction Tracking (ART)
CPRS: Authorization Subscription Utility (ASU)
CPRS: Clinical Reminders
CPRS: Consult/Request Tracking
CPRS: Health Summary
CPRS: Problem List
CPRS: Text Integration Utility (TIU)
Dentistry
Electronic Wait List
Emergency Department Integration Software (EDIS)
Functional Independence Measurement (FIM)
Group Notes
HDR - Historical (HDR-Hx)
Home Based Primary Care (HBPC)
OSEHRA AWG
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
Home Telehealth
Immunology Case Registry (ICR)
Incomplete Records Tracking (IRT)
Intake and Output
Laboratory
Laboratory: Anatomic Pathology
Laboratory: Blood Bank
Laboratory: Blood Bank Workarounds
Laboratory: Electronic Data Interchange (LEDI)
Laboratory: Emerging Pathogens Initiative (EPI)
Laboratory: Howdy Computerized Phlebotomy Login Process
Laboratory: National Laboratory Tests (NLT) Documents and LOINC Request Form
Laboratory: Point of Care (POC)
Laboratory: Universal Interface
Laboratory: VistA Blood Establishment Computer Software (VBECS)
Lexicon Utility
Medicine
Mental Health
Methicillin Resistant Staph Aurerus (MRSA)
Mobile Electronic Documentation (MED)
Nationwide Health Information Network Adapter (NHIN)
Nursing
Nutrition and Food Service (NFS)
Oncology
Patient Appointment Info. Transmission (PAIT)
12
WORKING DRAFT RFI: not for official use.
2011 VistA Clinical Application Packages
http://www.va.gov/vdl/section.asp?secid=1
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
Patient Assessment Documentation Package (PADP)
Patient Care Encounter (PCE)
Patient Record Flags
Pharm: Automatic Replenish / Ward Stock (AR/WS)
Pharm: Bar Code Medication Administration (BCMA)
Pharm: Benefits Management (PBM)
Pharm: Consolidated Mail Outpatient Pharmacy
Pharm: Controlled Substances
Pharm: Data Management (PDM)
Pharm: Drug Accountability
Pharm: Inpatient Medications
Pharm: National Drug File (NDF)
Pharm: Outpatient Pharmacy
Pharm: Prescription Practices (PPP)
Primary Care Management Module (PCMM)
Prosthetics
Quality Audiology and Speech Analysis and Reporting (QUASAR)
Radiology / Nuclear Medicine
RAI/MDS
Remote Order Entry System (ROES)
Scheduling
Shift Handoff Tool
Social Work
Spinal Cord Dysfunction
Standards & Terminology Services (STS)
76.
77.
78.
79.
80.
81.
Surgery
VistA Imaging System
VistAWeb
Visual Impairment Service Team (VIST)
Vitals / Measurements
Womens’ Health
13
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
2011 VistA Infrastructure Application Packages
http://www.va.gov/vdl/section.asp?secid=2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
Capacity Management Tools
Duplicate Record Merge: Patient Merge
Electronic Error and Enhancement Reporting (E3R)
Enterprise Exception Log Service (EELS)
FatKAAT
FileMan
FileMan Delphi Components (FMDC)
Health Data Informatics
HL7 (VistA Messaging)
Institution File Redesign (IFR)
KAAJEE
Kernel
Kernel Delphi Components (KDC)
Kernel Toolkit
Kernel Unwinder
List Manager
MailMan
Master Patient Index (MPI)
Medical Domain Web Services (MDWS)
M-to-M Broker
Name Standardization
National Online Information Sharing (NOIS)
National Patch Module
Network Health Exchange (NHE)
Patient Data Exchange (PDX)
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
Remote Procedure Call (RPC) Broker
Resource Usage Monitor
Single Signon/User Context (SSO/UC)
SlotMaster (Kernel ZSLOT)
SQL Interface (SQLI)
Standard Files and Tables
Statistical Analysis of Global Growth (SAGG)
Survey Generator
System Toolkit (STK)
VistA Data Extraction Framework (VDEF)
VistALink
XML Parser (VistA)
14
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
2011 VistA Financial-Administrative Application Packages
http://www.va.gov/vdl/section.asp?secid=3
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
Accounts Receivable (AR)
Auto Safety Incident Surv Track System (ASISTS)
Automated Information Collection System (AICS)
Automated Medical Information Exchange (AMIE)
Clinical Monitoring System
Compensation Pension Records Interchange (CAPRI)
Current Procedural Terminology (CPT)
Decision Support System (DSS) Extracts
Diagnostic Related Group (DRG) Grouper
Electronic Claims Management Engine (ECME)
Engineering (AEMS / MERS)
Enrollment Application System
Equipment / Turn-In Request
Event Capture
Fee Basis
Fugitive Felon Program (FFP)
Generic Code Sheet (GCS)
Health Eligibility Center (HEC)
Hospital Inquiry (HINQ)
ICD-9-CM
IFCAP
Incident Reporting
Income Verification Match (IVM)
Integrated Billing (IB)
Integrated Patient Funds
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
Library
Occurrence Screen
Patient Representative
Personnel and Accounting Integrated Data (PAID)
Police and Security
Quality Management Integration Module
Record Tracking
Release of Information (ROI) Manager
Veterans Identification Card (VIC/PICS)
Voluntary Service System (VSS)
Wounded Injured and Ill Warriors
15
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
2011 VistA HealtheVet Application Packages
http://www.va.gov/vdl/section.asp?secid=4
1.
2.
3.
4.
5.
Clinical Information Support System (CISS)
Electronic Signature (ESig)
HealtheVet Web Services Client (HWSC)
My HealtheVet
National Utilization Management Integration (NUMI)
6.
7.
8.
9.
10.
11.
Occupational Health Record-keeping System (OHRS)
Patient Advocate Tracking System (PATS)
Person Services
Registries
Spinal Cord Injury and Disorders Outcomes (SCIDO)
VA Enrollment System (VES)
12. Veterans Personal Finance System (VPFS)
16
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Suggested Plan of Actions and Milestones (POA&M) to
Refactor & Certify Legacy MUMPS within ESP Enabled System
1.
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 & integratedWORKING
applications
OSEHRA
AWG
DRAFTto
RFI:meet
not forKPPs
official use.
17
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Future State Architecture
GOAL
Incremental
Little Impact on links
between components
(e.g., Interoperability)
Innovation
Modular
Innovation
OBJECTIVE
A change-immune domain-specific
component-architecture emphasizing
interoperable standards-based services,
resulting-in simpler, loosely-coupled,
and less-costly module-level innovation.
Great impact on
components
Little impact on
components
PROBLEM
Little innovation, long lead
times and high costs
resulting from complex
highly-coupled components
Architectural
Innovation
Start
Great Impact on links
between components
(e.g., interoperability)
Radical
Innovation
19
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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
5.
•
ICD 9  ICD 10
•
ARRA Meaningful Use Objectives and criteria Stages I, II, III
•
HHS Mandated HITSP-constructs and HHS mandated standards
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Software Product Certification Criteria:
Safe, Compliant and Functional (2/3)
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
Bold Blue
indicates
“supported by
Architecture”
– 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
22
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Software Product Certification Criteria:
Safe, Compliant and Functional (3/3)
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Technical Vision: EHR Service Platform (ESP)
INTEGRATED EHR SOLUTION
EHR SERVICES PLATFORM (ESP)
Population
Health
Data &
Services
Population
Health
Data &
Services
EHR
Data &
Services
Registries
Data &
Services
EHR IS
Locator
Information Access & Longitudinal Record Services (LRS)
EHR Information Services (EHR IS)
Point of Service
Applications
Personal Health
Record Systems
EHR Viewers
24
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
•
•
•
•
•
•
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 domainspecific “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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Key Concepts: Federated EHR Services Platform
EHR IS
Enabled
Legacy System
INTEGRATED EHR SOLUTION
EHR IS
EHR SERVICES PLATFORM (ESP)
Tier 3
Plug-&-Play
Data Stores
Population
Health
Data &
Services
Population
Health
Data &
Services
EHR
Data &
Services
EHR IS
Enabled
PHR System
Registries
Data &
Services
EHR IS
Locator
ESP Based
System
EAI IP
Tier 2
EHR
Information
Services
Tier 1
Plug-&-Play
Applications
Data Access
Services Layer
Information Access & Longitudinal Record Services (LRS)
EHR Information Services (EHR IS)
EHR IP
EHR IP
EHR IP
Point of Service
Applications
Personal Health
Record Systems
EHR Viewers
Application
Services Layer
IP is SOA Interoperability Profile aka Service Interface
EAI is Enterprise Application Integration
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
26
TALKING POINTS: Benefits
The 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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Legacy Transition Strategy
INTEGRATED EHR SOLUTION
LEGACY EHR SYSTEM
EHR SERVICES PLATFORM (ESP)
EHR-IS ENABLED LEGACY INFRASTRUCTURE
Population
Health
Data &
Services
Data
Warehouse
Data &
Services
EHR
Data &
Services
Data
Warehouse
Data &
Services
Legacy
Point of
Service
Application
Registries
Data &
Services
EHR
Data &
Services
Personal
Health Record
System
Legacy
EAI IP
EHR-IS
EAI IP
Information Access & Longitudinal Record Services (LRS)
Information Access & Longitudinal Record Services (LRS)
EAI IP
Bi-Directional
Information
Exchange
EHR Information Services (EHR IS)
EHR IP
Point of
Service
Application
EHR IP
Personal
Health Record
Systems
EHR-IS
EHR Information Services (EHR IS)
EHR IP
EHR Viewer
EAI is Enterprise Application Integration
IP is SOA Interoperability Profile aka Service Interface
EHR-IS enabled legacy systems allow users to
transition at a convenient time and then legacy
systems can be gracefully shut down.
28
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
TALKING POINTS: Transition Strategy
based on ESP enabled systems
1. 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.
EHR Information Services (EHR IS) and
Common Information Integration Framework (CIIF) within EHR Services Platform (ESP)
EHR SERVICES PLATFORM (ESP)
ORGANISATIONAL INFOSTRUCTURE
Population Health Data
& Services
Registries Data
& Services
Client
Registry
Outbreak
Management
EHR Data
& Services
PHS
Reporting
Shared
Health Record
Drug
Information
Data Warehouse
& Services
Diagnostic
Imaging
Health
Information
Laboratory
Provider
Registry
Location
Registry
Business
Rules
EHR
Index
Terminology
Registry
Message
Structures
Normalization
Rules
Information Access & Longitudinal Record Services (LRS)
IP is SOA Interoperability Profile aka Service Interface
EAI IP
Security Mgmt
Rules/Data
EAI is Enterprise Application Integration
Privacy Mgmt
Rules/Data
Configuration
Rules/Data
EAI IP
Common Information Integration Framework (CIIF) and Common Services
EHR IS
Secure Communications Bus
EHR IP
Public Health
Services
Public Health
Provider
EHR IP
Pharmacy
System
Pharmacist
EHR IP
Radiology
Center
PACS/RIS
Radiologist
EHR IP
Lab System
(LIS)
EHR IP
Hospital, LTC,
CCC, EPR
Lab Clinician
Physician/
Provider
EHR IP
Physician
Office EMR
Physician/
Provider
EHR IP
EHR Viewer
Physician/
Provider
POINT OF SERVICE APPLICATIONS
30
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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 softwareservice 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.
ERH Services Platform (ESP) enabled system (conceptual view)
32
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Future State Architecture
Addressing Legacy-VistA Problems
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 opensource 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. Interchangeablecomponents 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.
33
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Approach to Architectural Traceability
Core Projects
Interoperability Projects
Plan for New, Improved, Sustained or Sunset
Capabilities
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
CUIs
Architectural
Business
Viewpoints
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
CUIs
Inventory of Systems and their
Capabilities and Functions
CUIs
Architectural
Information
Viewpoints
System
Architecture
CUIs
CUIs
CUIs
CUIs
CUIs
Architectural
Engineering/Technical
Viewpoints
Innovation/ Prototype Projects
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
Product Line
Inventory
Conceptual Independent Model
Platform Independent Model
Platform Specific Model
Architectural
Behavioral
Viewpoints
Conceptual Independent Model
Platform Independent Model
Platform Specific 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.
34
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
HL7 Service Aware Interoperability Framework (SAIF)
Enterprise Compliance and Conformance Framework (ECCF)
ECCF
Conceptual
Perspective
Logical
Perspective
Implementable
Perspective
Enterprise
Dimension
Information
Dimension
Computational
Dimension
“How” - Behavior
“Where” - Implementation
“Where” - Deployments
 Inventory of
• Domain Entities
• Activities
• Associations
• Information
Requirements
• Information Models
o Conceptual
o Domain
 Inventory of
• Functions-services
 Requirements
• Accountability, Roles
• Functional
Requirements, Profiles,
Behaviors, Interactions
• Interfaces, Contracts
 Inventory of
• SW Platforms, Layers
• SW Environments
• SW Components
• SW Services
• Technical
Requirements
• Enterprise Service Bus
 Key Performance
Parameters
 Inventory of
• HW Platforms
• HW Environments
• Network Devices
• Communication
Devices
 Technical Requirements
 Business Policies
 Governance
 Implementation Guides
 Design Constraints
 Organization Contracts
 Information Models
 Terminologies
 Value Sets
 Content Specifications
 Specifications
• Use Cases, Interactions
• Components, Interfaces
 Collaboration
Participations
 Collaboration Types &
Roles
 Function Types
 Interface Types
 Service Contracts
 Models, Capabilities,
Features and Versions for
• SW Environments
• SW Capabilities
• SW Libraries
• SW Services
• SW Transports
 Models, Capabilities,
Features and Versions for
• HW Platforms
• HW Environments
• Network Devices
• Communication
Devices
 Business Nodes
 Business Rules
 Business Procedures
 Business Workflows
 Technology Specific
Standards
 Schemas for
• Databases
• Messages
• Documents
• Services
• Transformations
 Automation Units
 Technical Interfaces
 Technical Operations
 Orchestration Scripts
 SW Specifications for
• Applications
• GUIs
• Components
 SW Deployment
Topologies
 HW Deployment
Specifications
 HW Execution Context
 HW Application Bindings
 HW Deployment Topology
 HW Platform Bindings
“Why” - Policy
 Inventory of
• User Cases, Contracts
• Capabilities
 Business Mission, Vision,
Scope
“What” - Content
Engineering
Dimension
Technical
Dimension
35
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Future-State Architecture
Software Development Kit (SDK)
Draft Specifications needed by Fall 2011 *
1.
Built-In-Test-Environment (BITE) Service Specification to support automated faultdetection 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 runtime 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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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 standardsbased services.
•
Database Services Specification of iEHR Tier 2-3 Database Virtualization-Layer of federated standardsbased 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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
39
NIST 7497 Security Architecture
Enabling 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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
NIST 7497 Security Architecture
Enabling 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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
NIST 7407 Security Architecture
Web-Service Security-Standards
42
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
NIST 7497 Security Architecture
Notional Development Process
43
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
PROVIDERS’ EHR DATA REUSE
ACROSS EPISODES OF CARE
Previous Episode
Of Care EHR
Current Episode
Of Care EHR
Reusable Services
IDENTITY
OSEHRA AWG
• Patient Demographics
• Provider Demographics
• Insurer Demographic
Data Must Be Verified
And Updated
Terminology
• Chronic Diagnoses
• Procedure History
Document
• Patient History
• Summary Lists
- Medication List
- Allergy/Adverse Reaction List
- Immunization
WORKING DRAFT RFI: not for official use.
44
Case-Managers’ EHR Data Reuse
Across the Continuum of Care
c CARE, PROVIDERS and LOCATIONS
COORDINATION ` ACROSS LEVELS OF
Wartime
Theater
ER
Acute
Inpatient
Acute
Rehab.
Chronic
Rehab.
Skilled
Long
Term
Care
Custodial
Long
Term
Care
Home
Health
Outpatient
Prevention/
Wellness
Care Continuum
Coordination ACROSS SOAS
ASSESSMENT
CARE
PLANNING
ORDERS
&
SCHEDULING
BENEFIT
MANAGEMENT
AUTHORIZATION
&
UTILIZATION MGT.
COMMUNICATION
(FACILITATION
ADVOCACY)
DISCHARGE/
TRANSFER
PLANNING
REFERRAL
RECORD
EDUCATION.
TRANSPORT
ROLE OF CASE MANAGER
45
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
HL7 EHR System
Functional Model (EHR-S)
(> 230 System Functions in 4 level categorization
(see attached spreadsheet for full enumeration)
Business
Choreography
System Functions
Business
Entity
(Information)
Business
Infrastructure
Entity
(Information)
Service Types
Choreography
Infrastructure
Infrastructure
Infrastructure
Business
Choreography
Other
OSEHRA AWG
O-1
Electronic Resource Planning (ERP)
O-2
Finances
7/16/2015
O-3
Other
WORKING DRAFT RFI: not for official use.
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.
Business
Capabilities
and Services
Services
interface layer
Business
process layer
SOA Layers
Focus on the Business Processes and Servic
orchestration service layer
business service layer
application service layer
Application
layer
System
Components
and Services
Source: Service-Oriented
Architecture, Thomas Erl
47
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
SOA Service Models
Potential Service Layers
Service Model
Application
Service
Business
Service
Controller
Service
Coordinator
Services
Entity-centric
Business Service
Hybrid
Service
Integration
Service
Process
Service
Task-Centric
Business Service
[Thomas Erl]
Description
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.
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.
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.
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.
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.
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.
An application service that also acts as an endpoint to a solution for cross-referencing integration purposes.
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.
A business process-specific variation of the business service that represents an atomic unit of process logic. Taskcentric 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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
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
Composite
Services
Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas
Core Business
Services
Functional
Areas + Focal Classes
Functional
Areas + Focal Classes
Functional
Areas + Focal Classes
Functional
Areas + Focal Classes
Entity
Services
Information
Management
Information
Management
Information
Management
Information
Reporting and
Management
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…)
Agnostic
Services
Application
Services
Ambulatory Care
Systems,
In Patient Care Systems
Logistics Systems
Financial Systems
Decision Support Systems
Data Marts
Repositories
Business Objects
Implementation
Profiles
OSEHRA
AWG
Integrated Healthcare
Enterprise (IHE) Profiles
Analysis Profiles
Communications
Profiles/Stacks
Implementation Profiles
WORKING DRAFT RFI: not for official use.
49
ANATOMY OF AN ANCILLARY SYSTEM
LABORATORY
RADIOLOGY
PHARMACY
CARDIOLOGY
OT/PT/SPEECH
s
ENABLING BUSINESS SERVICES
IDENTITY
TERMINOLOGY
AUTHORIZATION
SCHEDULING
SUPPLY CHAIN (ORDER/CHARGE)
DOCUMENT
RECORDS MANAGEMENT
DECISION SUPPORT
PERFORMANCE
DATA MANAGEMENT
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
50
RECORDS MANAGEMENT
DECISION SUPPORT
PERFORMANCE
Agnostic
Services
DATA MANAGEMENT
OSEHRA AWG
ANALYTIC
SUPPORT
IT PLATFORM
WORKING DRAFT RFI: not for official use.
INTEGRATED
REQUIREMENTS
DESIGNS:
Putting the
H-SOA-RA
Pieces Together
Federated
Business
Services
Inter-Service
Inter-Agency
Across
Providers
DOCUMENT
OUTPATIENT OTHER
SUPPLY CHAIN:
(ORDERS/CHARGES)
ER
SCHEDULING
ASU
AUTHORIZATION
CLINIC
Enabling Business
Services
TERMINOLOGY
INPATIENT
IDENTITY
TEST ONLY
Ancillary
Systems
Federated Services,
may be categorized by:
-- Encounter Types
-- CMS billing category
-- Record type
-- Care setting type
-- etc.
Data sets are defined for
each system functionalcapability-service module
51
Addressing Real Business Issues Through
H-SOA-RA based Integrated Requirements-Design
•
•
•
•
•
•
•
Incomplete/Inaccurate Demographic Data
Incomplete/Inaccurate Insurance Information
Unauthorized Service
Diagnosis/Procedure Coding Errors
Service Delays
Incomplete and Inefficient Charge Capture
Non-indicated or Contra-indicated Services
(Identity Service)
(Authorization Service)
(Authorization Service)
(Terminology Service)
(Scheduling Service)
(Supply Chain Service)
(Decision Support/
Authorization Services)
• Delays in EHR Document Production and Provision
• Billing Delays and Errors
• Not fully coordinated Scheduling
• Lack of fully integrated Patient Assessment and Treatment Plan
• Delayed or Lack of Medical Record Access
(Document Service)
(Supply Chain/ Billing/
Collection Services)
(Scheduling Service)
(Document Service/
Decision Support Service)
(Record Service)
52
OSEHRA AWG
WORKING DRAFT RFI: not for official use.
Contact Information
and Initial Plan
• tiag® is the prime contractor. tiag® is an SBA certified 8(a) womanowned, 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
OSEHRA AWG
WORKING DRAFT RFI: not for official use.