Download
1 / 88
890 likes | 1.23k Views
2. Agenda. Introduce the MHS Enterprise ArchitectureDemonstrate the Version 2.0 web-based modelDiscuss the value of integrating clinical, SDO initiatives with the MHS Enterprise Architecture. 3. Military Health System Information Management/Information Technology Program Strategic Planning. . .
E N D
2. 2 Agenda Introduce the MHS Enterprise Architecture
Demonstrate the Version 2.0 web-based model
Discuss the value of integrating clinical, SDO initiatives with the MHS Enterprise Architecture
3. 3 Military Health System Information Management/Information Technology Program Strategic Planning
4. 4 Military Health System Information Management/Information Technology Program Strategic Planning Framework
5. 5 What Is An Enterprise Architecture? An Enterprise Architecture is an integrated model consisting of Operational, Systems, and Technical views defining the enterprises:
Mission and business activities
Information needed for operations
Technologies needed to support operations
Migration plans to implement new processes and technologies to support changing business activities
6. 6 Benefits of an Enterprise Architecture Aligns IM/IT support with business objectives and provides a unified enterprise-wide vision.
Implements best practices and principles to rapidly implement solutions in response to emerging business needs.
Employs a consistent framework that better supports future technology decisions.
Provides a mechanism to make more effective IM/IT investments
Helps apply enterprise-wide IM/IT standards and processes.
GAO Compliance
7. 7 MHS Architecture Drivers Health Affairs CIO has mandate to comply with Federal and DoD Architecture Guidance Clinger-Cohen Act, C4ISR Architecture Framework, and DoD Global Information Grid (GIG)
Understand HIPAAs impact on MHS operational requirements, current systems, and technical standards
Leverage DoD eBusiness Project Office and Army Medical Architectures (theater-level) to build the MHS Architecture and link to others (e.g. VHA), and generate others (e.g. Theater Medical)
Makes good business sense maximizes system integration and development of complex systems
Clinger-Cohen Act requires that the head of each Agency establish an effective and efficient capital planning and investment control process for selecting, managing, and evaluating major IT investments.
ensure that IT investments are compliant with the agency's IT architecture
Clinger-Cohen Act requires that the head of each Agency establish an effective and efficient capital planning and investment control process for selecting, managing, and evaluating major IT investments.
ensure that IT investments are compliant with the agency's IT architecture
8. 8 How will the Architecture be used? Support planning and decision making (e.g., capital planning and investment, business process redesign)
Identify opportunities for increased interoperability and information sharing
Identify opportunities for taking advantage of new technologies and standards (e.g., for e-government)
Support analysis of alternatives, risks, and trade-offs
As an educational tool for understanding MHS Business Processes
9. 9 An Architecture is Described in Terms of Three Linked Views The operational view describes the tasks and activities, operational elements, and information flows required to accomplish or support a mission or functional area.
The systems view describes systems and interconnections that support the activities of interest.
The technical view is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements.
To be consistent and integrated, an architecture must provide explicit linkages among its views. Such linkages are also needed to provide a cohesive audit trail from integrated mission operational requirements and measures of effectiveness to the supporting systems and their characteristics, and to the specific technical criteria governing the acquisition/development of the supporting systems.
The operational view describes each needlines information exchange in detail sufficient to determine what specific degree of information-exchange interoperability is required. The systems view identifies which systems support the requirement, translates the required degree of interoperability into a set of system capabilities needed, and compares current/postulated implementations with the needed capabilities. The technical view articulates the criteria that should govern the compliant implementation of each required system capability.
The operational view describes the tasks and activities, operational elements, and information flows required to accomplish or support a mission or functional area.
The systems view describes systems and interconnections that support the activities of interest.
The technical view is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements.
To be consistent and integrated, an architecture must provide explicit linkages among its views. Such linkages are also needed to provide a cohesive audit trail from integrated mission operational requirements and measures of effectiveness to the supporting systems and their characteristics, and to the specific technical criteria governing the acquisition/development of the supporting systems.
The operational view describes each needlines information exchange in detail sufficient to determine what specific degree of information-exchange interoperability is required. The systems view identifies which systems support the requirement, translates the required degree of interoperability into a set of system capabilities needed, and compares current/postulated implementations with the needed capabilities. The technical view articulates the criteria that should govern the compliant implementation of each required system capability.
10. 10 Operational Architecture Sources The MHS Optimization Plan
The MHS Future State Business Process Model
Approved by MHS Management
Developed by MHS with contractor support
A set of MHS business processes and activities
Forms the basis of the architecture activities (OV-5)
Contributed to the architecture operational nodes (OV-2)
Forms the basis of the architecture information exchanges (OV-2)
The MHS Functional Area Model Activity (FAM-A)
Developed by MHS functional workgroups with contractor support
Forms the basis of the architecture information exchanges (OV-3s)
11. 11 Operational Architecture Sources (Contd) Subject Matter Experts
Functional validation sessions (Sept 19 Dec 18 01; 15 19 April 02)
Covered all 4 core processes
Army Medical Department (AMEDD) Operational Architecture
Mapped AMEDD Operational Architecture to MHS Operational Architecture (June 01 Jan 02)
AMEDD areas included:
Medical Logistics (Combat Health Logistics)
Health Care Delivery
Health Service Command and Control
Evacuation
Medical Force Protection
12. 12 MHS Enterprise Architecture Version 2.0 Products
15. 15 Discuss OV products
Steve Introduction 5 minutes to tell what Steve will do
Steve Thread through 1.3.2 8 minutes
for OV-2s
discuss OV-3s 5 minutes
Steve and Nancy discuss additional topic items if Force Health Protection needed 10 minutes
Issue: in the later components that deal with aggregating individual transactional information (I.e. Pop Health and Manage the Business particularly) there were no clearly defined roles or data stores for the information gathered by the activity. You can see the lower level box discusses data marts and DSSs, but no specifics like the CDR. Hence, the evolution of pop health data repository, development of roles such as of Enterprise Business Managers/General Administrators. There was no clear output for several activities, particularly those that monitored or managed or ensured and without that, we couldnt loop them back as inputs into access to care, or provision of health.
Example: Start with 3.14 Identify Force Health Threats, to 3.2.2 Develop Care Models and Mgmt Plans for Targeted Populations , then to 1.2.2 Assess Need for Service(s) or, and then to 2.1.1. Evaluate Beneficiary Health Status (can also then feed 4.5.2 Monitor Medical Performance (where they produce case review results), 3.3.5 Manage Occupational/Environmental Threats, and/or 4.6.3 Planning and Forecasting (through review of current programs/protocols and recommending improvement strategies).
Follow IE thread of Environmental Risk Assessment or Environ/Pop Hlth Info as its developed in 3.14. It becomes an input to 3.2.2 and what comes out is a developed Pop Risk Reduction Plan that becomes part of Screening/Treatment Protocols and is also stored in the Pop Health Repository. (In real life it also goes to Health Education or the CINC as part of Ops Plans). When the beneficiarys need for service is assessed in 1.2.2., the triage provider can refer to the Pop Risk Reduction Plan and/or Screening/Treatment Protocols to determine which care provider to send the beneficiary to. It then is used by that care provider in 2.1.1 when she/he Evaluates the Beneficiary Health status to make a health status determination.
Occ/Environmental Threat Mgmt ( 3.3.5) may refer to collected care mgmt information in 3.3.5 and compare it to the risk reduction plans, and current environmental risk assessment in order to manage the threats. OR Manage the Businesss Monitoring of Medical Performance which looks at case review results, may compare the procedures documented in the case review to the Risk Reduction Plan/Screening/Treatment Protocols recommended.
Discuss OV products
Steve Introduction 5 minutes to tell what Steve will do
Steve Thread through 1.3.2 8 minutes
for OV-2s
discuss OV-3s 5 minutes
Steve and Nancy discuss additional topic items if Force Health Protection needed 10 minutes
Issue: in the later components that deal with aggregating individual transactional information (I.e. Pop Health and Manage the Business particularly) there were no clearly defined roles or data stores for the information gathered by the activity. You can see the lower level box discusses data marts and DSSs, but no specifics like the CDR. Hence, the evolution of pop health data repository, development of roles such as of Enterprise Business Managers/General Administrators. There was no clear output for several activities, particularly those that monitored or managed or ensured and without that, we couldnt loop them back as inputs into access to care, or provision of health.
Example: Start with 3.14 Identify Force Health Threats, to 3.2.2 Develop Care Models and Mgmt Plans for Targeted Populations , then to 1.2.2 Assess Need for Service(s) or, and then to 2.1.1. Evaluate Beneficiary Health Status (can also then feed 4.5.2 Monitor Medical Performance (where they produce case review results), 3.3.5 Manage Occupational/Environmental Threats, and/or 4.6.3 Planning and Forecasting (through review of current programs/protocols and recommending improvement strategies).
Follow IE thread of Environmental Risk Assessment or Environ/Pop Hlth Info as its developed in 3.14. It becomes an input to 3.2.2 and what comes out is a developed Pop Risk Reduction Plan that becomes part of Screening/Treatment Protocols and is also stored in the Pop Health Repository. (In real life it also goes to Health Education or the CINC as part of Ops Plans). When the beneficiarys need for service is assessed in 1.2.2., the triage provider can refer to the Pop Risk Reduction Plan and/or Screening/Treatment Protocols to determine which care provider to send the beneficiary to. It then is used by that care provider in 2.1.1 when she/he Evaluates the Beneficiary Health status to make a health status determination.
Occ/Environmental Threat Mgmt ( 3.3.5) may refer to collected care mgmt information in 3.3.5 and compare it to the risk reduction plans, and current environmental risk assessment in order to manage the threats. OR Manage the Businesss Monitoring of Medical Performance which looks at case review results, may compare the procedures documented in the case review to the Risk Reduction Plan/Screening/Treatment Protocols recommended.
17. 17
18. Walk-through Demonstration of the MHS Enterprise Architecture 2.0
19. 19
20. 20
21. 21
22. 22
23. 23
24. 24
25. 25
26. 26
27. 27
28. 28
29. 29 MHS Operational Architecture Products Discuss OV products
Steve Introduction 5 minutes to tell what Steve will do
Steve Thread through 1.3.2 8 minutes
for OV-2s
discuss OV-3s 5 minutes
Steve and Nancy discuss additional topic items if Force Health Protection needed 10 minutes
Issue: in the later components that deal with aggregating individual transactional information (I.e. Pop Health and Manage the Business particularly) there were no clearly defined roles or data stores for the information gathered by the activity. You can see the lower level box discusses data marts and DSSs, but no specifics like the CDR. Hence, the evolution of pop health data repository, development of roles such as of Enterprise Business Managers/General Administrators. There was no clear output for several activities, particularly those that monitored or managed or ensured and without that, we couldnt loop them back as inputs into access to care, or provision of health.
Example: Start with 3.14 Identify Force Health Threats, to 3.2.2 Develop Care Models and Mgmt Plans for Targeted Populations , then to 1.2.2 Assess Need for Service(s) or, and then to 2.1.1. Evaluate Beneficiary Health Status (can also then feed 4.5.2 Monitor Medical Performance (where they produce case review results), 3.3.5 Manage Occupational/Environmental Threats, and/or 4.6.3 Planning and Forecasting (through review of current programs/protocols and recommending improvement strategies).
Follow IE thread of Environmental Risk Assessment or Environ/Pop Hlth Info as its developed in 3.14. It becomes an input to 3.2.2 and what comes out is a developed Pop Risk Reduction Plan that becomes part of Screening/Treatment Protocols and is also stored in the Pop Health Repository. (In real life it also goes to Health Education or the CINC as part of Ops Plans). When the beneficiarys need for service is assessed in 1.2.2., the triage provider can refer to the Pop Risk Reduction Plan and/or Screening/Treatment Protocols to determine which care provider to send the beneficiary to. It then is used by that care provider in 2.1.1 when she/he Evaluates the Beneficiary Health status to make a health status determination.
Occ/Environmental Threat Mgmt ( 3.3.5) may refer to collected care mgmt information in 3.3.5 and compare it to the risk reduction plans, and current environmental risk assessment in order to manage the threats. OR Manage the Businesss Monitoring of Medical Performance which looks at case review results, may compare the procedures documented in the case review to the Risk Reduction Plan/Screening/Treatment Protocols recommended.
Discuss OV products
Steve Introduction 5 minutes to tell what Steve will do
Steve Thread through 1.3.2 8 minutes
for OV-2s
discuss OV-3s 5 minutes
Steve and Nancy discuss additional topic items if Force Health Protection needed 10 minutes
Issue: in the later components that deal with aggregating individual transactional information (I.e. Pop Health and Manage the Business particularly) there were no clearly defined roles or data stores for the information gathered by the activity. You can see the lower level box discusses data marts and DSSs, but no specifics like the CDR. Hence, the evolution of pop health data repository, development of roles such as of Enterprise Business Managers/General Administrators. There was no clear output for several activities, particularly those that monitored or managed or ensured and without that, we couldnt loop them back as inputs into access to care, or provision of health.
Example: Start with 3.14 Identify Force Health Threats, to 3.2.2 Develop Care Models and Mgmt Plans for Targeted Populations , then to 1.2.2 Assess Need for Service(s) or, and then to 2.1.1. Evaluate Beneficiary Health Status (can also then feed 4.5.2 Monitor Medical Performance (where they produce case review results), 3.3.5 Manage Occupational/Environmental Threats, and/or 4.6.3 Planning and Forecasting (through review of current programs/protocols and recommending improvement strategies).
Follow IE thread of Environmental Risk Assessment or Environ/Pop Hlth Info as its developed in 3.14. It becomes an input to 3.2.2 and what comes out is a developed Pop Risk Reduction Plan that becomes part of Screening/Treatment Protocols and is also stored in the Pop Health Repository. (In real life it also goes to Health Education or the CINC as part of Ops Plans). When the beneficiarys need for service is assessed in 1.2.2., the triage provider can refer to the Pop Risk Reduction Plan and/or Screening/Treatment Protocols to determine which care provider to send the beneficiary to. It then is used by that care provider in 2.1.1 when she/he Evaluates the Beneficiary Health status to make a health status determination.
Occ/Environmental Threat Mgmt ( 3.3.5) may refer to collected care mgmt information in 3.3.5 and compare it to the risk reduction plans, and current environmental risk assessment in order to manage the threats. OR Manage the Businesss Monitoring of Medical Performance which looks at case review results, may compare the procedures documented in the case review to the Risk Reduction Plan/Screening/Treatment Protocols recommended.
30. 30
31. 31
32. 32
33. 33
34. 34
35. 35
36. 36
37. 37
38. 38
39. 39
40. 40
41. 41
42. 42
43. 43
44. 44
45. 45
46. 46
47. 47
48. 48
49. MHS Systems Architecture Products
50. 50
51. 51
52. 52
53. 53
54. 54
55. 55
56. 56
57. 57
58. 58
59. 59
60. 60
61. 61
62. 62
63. 63
64. 64
65. 65
66. 66 New Operational (Business) View Supporting Products in version 2.0
Data Entity to Activity CRUD
Logical Data Model (OV-7) Reference
Activity (OV-5) to Future Business Process Scenario links
MHS to VHA Activity Mappings
MHS to Army Medical Activity Mappings
67. 67
68. 68
69. 69
70. 70
71. 71
72. 72
73. MHS Special Reports MHS Enterprise Architecture 2.0
74. 74
75. 75
76. 76
77. 77
78. 78
79. 79
80. 80
81. 81
82. 82
83. 83 Data Questions How Architecture Can Help
84. 84 Architecture Supports System/Business Questions
85. For Further Information about the MHS Enterprise Architecture contact mhs.architecture@tma.osd.mil and coming soon: http://www.tma.osd.mil/architecture
86. 86 Discussion & Questions
87. Backup Slides
88. 88 MHS Technical Architecture Profile TV -1
