1 / 88

MHS Enterprise Architecture Orientation Briefing

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. . .

gada
Download Presentation

MHS Enterprise Architecture Orientation Briefing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    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 enterprise’s: 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 HIPAA’s 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 needline’s 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 needline’s 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 (Cont’d) 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 couldn’t “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 it’s 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 beneficiary’s 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 Business’s 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 couldn’t “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 it’s 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 beneficiary’s 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 Business’s 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 couldn’t “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 it’s 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 beneficiary’s 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 Business’s 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 couldn’t “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 it’s 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 beneficiary’s 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 Business’s 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

More Related