Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Mdds sundararaman 12th meeting

197 Aufrufe

Veröffentlicht am

Mdds sundararaman 12th meeting

Veröffentlicht in: Gesundheit & Medizin
  • Discover How to Cure uterine fibroids and PCOS At Any Age, Even If You’ve Tried Everything And Nothing Has Ever Worked For You Before ▲▲▲ https://bit.ly/2ONPXxg
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

Mdds sundararaman 12th meeting

  1. 1. Meta Data & Data Standards for Health Domain Dissemination Workshop 12th December 2013
  2. 2. • Initiated under National e-Governance Plan (NeGP) by DeitY. • Aims to promote- e-Governance by making systems speak to each other. • Domain specific committees constituted –Health MDDS Domain committee constituted on Sept. 2012. – Chairperson - Joint Secretary (Policy), Sr. Technical Officer (NIC) as member-secretary. – Secretariat- National Health System Resource Centre (NHSRC). – Tasks of Secretariat- Stakeholder Consultations, selecting appropriate technical agencies to support this work and Domain Expertise. – Members from public health programme divisions, industry, IT domain experts, NIC, Meta Data & Data Standards- The Initiative
  3. 3. Terms of Reference: 1. To identify Generic Data Elements in the health domain, which are common across e-Governance applications within the domain as well as other domains involved in providing sectoral services delivery under e-governance. 2. To study the Global Standards for standardising the metadata of identified generic data elements for adoption as Indian standards. 3. To develop own standards / extension of global standards in Indian context, wherever required, around policy on Open Standards, (and in synergy with other domain committees by following Institutional Mechanism for formulation of Domain specific MDDS formulation published by DietY). MDDS Health Domain Project - Mandate
  4. 4. Mandate of MDDS Committee…. 4. Create and maintain repository of metadata of standardised generic standards, and include the same in central repository by having liaison with e-Gov standards Div, NIC. 5. Ensure enforcement of standards in the applications being developed in health domain at central/ state Government level. 6. To advise for identification of suitable test suits for conformance testing of the implementation.
  5. 5. • Malaria Control • State Health Management Information Systems- In seven States with Hospital Information Systems. • Routine Immunization Management Program • Sporadic use in Medical College Hospitals The first generation IT systems are characterized by low expectations, effectiveness and complexity.. The 1st Generation Systems (1993–2005)
  6. 6. • The National Health Management Information System- common Web- Portal with entry- States develop a large number of systems- 1.Human Resource Management Information System. 2.Hospital Information Systems 3.Disease Surveillance Systems 4.Drug Logistics and Inventory Systems 5.E- Tendering and Procurement Systems 6.Clinical Establishments Licensing and Regulation 7.Emergency Call Centre and Ambulance Services 8.Mother and Child Tracking Systems- over 6 crore records. 9.Financial Transaction Recording Systems 10.Major initiatives in Tele-medicine. 11.Mobile Health , Insurance etc etc. 2nd Generation Systems National Rural Health Mission Catalyzed
  7. 7. Main Positives of the Second Phase • IT is now seen as mandatory in all aspects of health systems management. • High degrees of complexity and sophistication in systems. • Rapidly accelerating expectations. • For example : From 600 district reports (2008), to 5000 block block reports ( 2011) to 2 lakh facilities( 2012), to 6 crore mothers and children, below 2 !!!!! • AND NOW to every health encounter ???
  8. 8. BUT the problem : All Public Health IT Systems in silos Nutrition Block Facility MCTS – Reprod. & Child Health System at National Level NACO National Disease Program Hospital Informati on Systems, EMR State Health Program s e.g. EMRI, eMamta, HMIS, DHIS Birth & Deaths Private Sector MOHFW District Admin State HQ Directorates e.g. Malaria, IDSP, NACO IDSP National Disease Program Malaria National Disease Program RNTCP National Disease Program Web portal – Reprod. & Child Health System at National Level o Every program/ state develops own IT solutions. States have 10 to 30 systems o No help to integrated decision making for Public Health management. o State to central exchange very poor- and even at the same level. o Systems a struggling with poor design and falling short of objectives. o Private Providers not participating in information exchange.
  9. 9. Importance of Inter-operability realized. • In Public Systems: – To reduce work load in data recording and entry. – To support decentralized , horizontally integrated decision making. – To improve quality and use of information. – To allow rapid growth of new systems and uses of IT. • For Providers AND Patients – to improve quality of care – To enable continuity of care • For Insurance Payers – access to patient records for claims settlements: 3rd Phase- (2012 onwards): From IT Systems to IT Architecture… .
  10. 10. Three Levels of Interoperability: MDDS Builds Semantic Operability Institutional Interoperability Syntactic Interoperability Semantic Interoperability
  11. 11. The Process  Consultation with key stakeholders- MoHFW, NIC, C-DAC, MMP, HISP, International Domain Experts, health care IT industry, Program Managers, EHR Committee etc.  Review of Documents –EHR Standards, MMP, 12th Five Year Plan, Public Health IT Systems Study, System Manuals, Program Guidelines, MDDS Standard Document  Refer Global Data Standards- ICD-10, CPT, SNOMED, CCI, ICHI, ICF, WHO Morbidity & Mortality Codes, LOINC  Refer Globally recognized Interoperability Standards –HL7 V2.X, V3, CCD, SDMX.  Study of public IT Systems- HMIS Web Portal, MCTS, DHIS 2.0, IDSP, Nikshay- RNTCP, iHRIS, e-Aushadhi
  12. 12. The Output MDDS Report Name Description Part I Overview Report •Design Principles - Semantic Theory & its application in Health Domain •Roll-out mechanism, Institutional framework. •Integration Solutions. Part II Data Element Quick Reference List of 1077 Data Elements with their definitions and Values Part III Code Directories •Code Directory List, •Sample Values •Meta Data for Code Directory Part IV Data Element Meta Data Meta Data for Each Data Element. Including Data Element Type, Format, Size, Validation, Values, Default Value, Owner etc. Annexure •Data Sets- Inventory, Blood Bank etc. •Some examples of data sets created form the common data elements. •Interim Measures Integration & Upgrade as per MDDS •Integration Solutions for existing system- HMIS-MCTS, DHIS-iHRIS •MDDS Mapping with HMIS. IDSP & RNTCP Systems •Part II, III & IV and Annexure are in soft copy in CD. •For online access visit- http://mohfw.nic.in, www.nhsrcindia.org
  13. 13. MDDS Health Domain Standards Building Blocks of MDDS Health Domain o The health domain landscape are broadly divided into 39 Entities. o These entities are described and qualified with the help of 1077 Data Elements. o Values of Data Elements are categorized under Data Elements (735), Values List (201) & Code Directories (141) o Meta Data are constructed to define each Data Element and Code Directory to establish Interoperability Standards o Interoperability Standards o Reference Architecture for Interoperability
  14. 14. MDDS The Conceptual Design Example-I CONCEPTUAL DOMAIN ENTITY (E.G. PHARMACY ORDER) LIST OF VALUES (BID, TID, QID,HS, STAT) OBJECT CLASS MEDICATION ORDERS ATTRIBUTE FREQUENCY DATA ELEMENT MEDICATION FREQUENCY CONCEPT FREQUENCY OF MEDICATION VALUE DOMAIN MEDICATION FREQUENCY CODE DIRECTORY
  15. 15. MDDS The Conceptual Design Example-II Concept Operational Status of Facility Value Domain Operational Status Value List Conceptual Domain Entity (e.g. Facility) Object Class Facility Attribute Operational Status List of Values Functional, Non- Functional, Under Repair , Closed, Data Element Facility Operational Status
  16. 16. MDDS The Conceptual Design Example-III Concept Health Condition Code Value Domain ICD-10 Code Directory Conceptual Domain Entity (e.g. Diagnosis) Object Class Health Condition Attribute Code List of Values ICD-10 Disease Codes Pulmonary Tuberculosis - Lab Confirmed Values: A15 Data Element Health Condition Code
  17. 17. MDDS The Conceptual Design Example-IV Concept Scheduled Ambulance Trip Reasons Value Domain Medical Reason for Scheduled Trip Code Directory Conceptual Domain Entity (e.g. Ambulance) Object Class Ambulance Attribute Scheduled Trip Reasons List of Values Delivery, RTA, chest pain, -drawn from ICD and WHO Data Element Reasons for Scheduled Ambulance Trip
  18. 18. Common Data Elements • Defining Minimum Data Elements as standards is difficult in Health Domain. • Minimum Data needs of the Primary Care Setting would be different from the Secondary and Tertiary Care Settings. • Health Domain has come-up with the Common Data Elements which will act as superset from which program specific data sets can be created. • Data Set design is better left to the users.
  19. 19. Common Data Element - ENTITIES Description of Entities Entity No. of Data Elements Entity No. of Data Elements Generic 35 Lab 39 Person 32 Radiology 10 Patient 21 Pharmacy 32 Employee 155 Immunisation Order 10 Provider 16 Clinical Order 19 Source of Payment 38 Procedure 8 Bill 39 Blood Bank 36 Facility 32 Nursing 21 Episode 2 OT 33 Encounter 9 CSSD 20 Advance Directives 6 Inventory 179 ADT 56 Remission 5 Emergency 19 Complications 5 Outreach 11 Relapse 5 Disaster Response 31 Morbidity 6 Examination 5 Disability 7 Vital Signs 16 Mortality 6 Allergy 13 Ambulance 66 Clinical Notes 15 Indicator 5 Diagnosis 14 Total 1077
  20. 20. Common Data Elements: Snapshot Entity- Diagnosis Number Name of Data Element Data Format Maximum Size 05.020.0001 Health Condition Type Integer 2 05.020.0002 Health Condition name Varchar 99 05.020.0003 Health Condition Code Varchar 10 05.020.0004 Health Condition Free text Varchar 254 05.020.0005 Health Condition Category Char 1 05.020.0006 Diagnosis Priority Char 1 05.020.0007 Health condition status Integer 2 05.020.0008 Co-morbidity Flag Integer 1 05.020.0009 Co-morbidity Health Condition Code Varchar 10 05.020.0010 Present Health Condition Onset Date Custom 05.020.0011 Prognosis Integer 2
  21. 21. Complexities Pushed to Code Directories Code Directory Facts:  Total Code Directory- 141  Code Directory Populated-111 (79%)  Code Directory Derived from established sources- 42%  7 Code Directories - Facility Master. Ref No Name of Code Directory Ownership & Source CD05.001 Facility Master MDDS Committee CD05.019 ICD - 10 Codes WHO CD05.024 LOINC LOINC CD05.030 System of Medicine MDDS Committee CD05.036 Immunization Product WHO CD05.043 Procedure Code Canadian Classification of Health Intervention (CCI) CD05.056 WHO List for General Mortality WHO CD05.059 WHO International Classification of Functioning, Disability and Health (ICF) WHO CD05.104 Generic Drug National Formulary of India CD05.109 Pharmaceutical Unit of Measurement Food and Drug Administration CD05.118 Third Party Administrator IRDA CD05.130 Medical Reasons for Scheduled Ambulance Trip LOINC & WHO
  22. 22. Identity Management in Indian Health System • Health information exchange between systems through Identifiers – Facility Identifiers (Unique Facility Identification Number/Global Unique Identifier) – Provider Identifiers – Unique Individual Health Care Provider Number – Patient Identifiers– UID/ Alternate Unique Identification Number – Disease Identifiers– ICD-10 Codes – Service Identifiers– CCI Codes – Document Identifiers– Document ID
  23. 23. Facility Identity Management Unique Facility Identification I. Facility Signature Domain: – Unique Facility Identification Number – Global Unique Identifier – Type of Facility – Address – Geocode – Difficulty status- Easy/Difficult – Rural/Urban Area – Population covered – Administrative linked parent facility Type – Operational Status – Referral facility – Ownership Authority & Type II. Facility Services Domain: – Facility System of Medicine Type – Facility Services Master III. Facility Human Resource Domain IV. Facility Infrastructure Domain: – Facility Bed Master – Facility Bed Type Master Suggested Model – Central Model
  24. 24. Further gains of this effort… • Gone far beyond just clinical terminology standardization: Set standards - administrative and operational parameters • MDDS provides platform to dramatically accelerate use of EHR standards/HL7/DICOM communication standards. • Now in a position to be a global leader in healthcare IT useage and implementations. Global Governments could also use MDDS as a base and modify it for their local healthcare industry . • Allows greater democracy – in choose their own systems and software applications, vendors and technical infrastructure : within a ‘standards’ framework that ensure national consistency in the reporting and management of healthcare outcomes.
  25. 25. The Second Level of Interoperability: Appropriate Integration Solutions will ensure Syntactic Interoperability Institutional Interoperability Syntactic Interoperability Semantic Interoperability
  26. 26. Point-to-point Integration  Pros • Useful for all historical applications without much disruptive changes. • One eligible application can receive message from a source application message channel.  Cons • Extra effort, time and cost to write Transformation logic for each application. • Semantic interoperability difficult to implement across different applications. <?xml version=“1.0” ?> <Group group_id=1> <dataelement> <HMIS_dataelement>id=” M1|1.1” name=” Total Number of Pregnant Woman Registered for ANC” Value”</HMIS_dataelement> <MCTS_dataelement> id=“1” value=“100” isChild=”F”</MCTS_dataelement> </dataelement> <dataelement> <HMIS_dataelement>id=” M1|1.1.1” name=” Of which Number Registered with in First Trimester”</HMIS_dataelement> <MCTS_dataelement> id=“2” value=“30” isChild=”T” Parentdataelement=”M1|1.1”</MCTS_dataelement> </dataelement> <FacilityCode> 00000000023</FacilityCode> <FacilityType>”SC”</FacilityType> <REPORTING_PERIOD> <TYPE>”Monthly”</TYPE> <FROM_VALUE>=”July 2013”</FROM_VALUE> <TO_VALUE>=”July 2013”</TO_VALUE></REPORTING_PERIOD> </Group> Spaghetti framework
  27. 27. Broker-Based Integration  Pros • Message broker can be used to receive messages, transform and route to recipient application (Hub and spoke architecture.) • Data from finite set of disparate applications can be integrated using this.  Cons • Data discovery at run time based on a service request is difficult. • May lead to a highly complex architecture- difficult to maintain.
  28. 28. Intelligent Gateway (Health Information Exchange) • Better suited to current context. • Based on Registry architecture pattern. • Allows to dynamically locate the data records and the application locations. • Integration with other domain applications is quite easy.
  29. 29. Choosing Integration Options If within range of Tower in Mumbai Circle, it has a registry lookup to connect the 2 o Condition - II o Broker Integration • Condition - I • Point to Point Integration √ Condition - III √ Exchange Integration • Any No. of Apps. • Need to know where the book is located in the Library. Else it is like trying to find any book without library catalogue • Limited No. of Historical apps. • If Time & Effort not a constraint • Scalable to any number of systems. • Historical apps cant be retired. • MDDS implementation with deviations- Real world • Intelligent broker is like - Searching a book in electronic catalogue – E.g. Amazon Books. HOT Line Roaming Mobile from Bangalore Circle Roaming Mobile from Delhi Circle Trunk Dialing – Operator needs to know where to route the call
  30. 30. Third Level of Interoperability Set of rules, guidelines on the way we collect and report data- and of course the desire to dialogue and share: Institutional Interoperability Syntactic Interoperability Semantic Interoperability
  31. 31. Institutional Interoperability  Guidelines, norms for data collection and reporting, patterns of flow, aggregation and context of usage.  Different levels of digital capacity, different granularities of reporting,  Choice of standard, Indicators for data exchange.  Most importantly a dialogue between organizations, to understand information needs, as well as barriers to better quality and use of information.  National Authority should be able to facilitate this role.
  32. 32. Key Principles: Follow-up and Roll-out 1. Data standards are seen as dynamic- provision to be made for constant upgradation and corrections. 2. Even the starting standards as released now, will need clarifications, corrections, additions, deletions- standing committee to help to this. 3. In private sector, the adoption would be voluntary- driven by the advantages and ease of doing so. 4. In public sector it would be driven by financing conditionality and needs for sharing information. 5. Once standards prove themselves, and ecosystems to test and certify measure a mix of financial incentives and disincentives for private sector could be considered.
  33. 33. Standards Roll-out and Adoption–The Steps a. All centrally financed applications and software should comply with these standards. This will be part of the sanction of funds. b. Specific proposals received to reengineer available public health IT products to confirm to standards can be taken-up on Case to case basis. Same would not be applicable to new applications. c. Adherence to standards- The MDDS committee may consider accreditation and rate contracting suitable testing agencies and only these may be allowed. d. Creating Awareness- All major health IT symposia and seminars to be covered to explain and popularise standards so that industry voluntarily adopts the standards even solely for private purposes.
  34. 34. Standards Roll-out contd.. e. Standards Updation- Suggestions, complaints, technical snags should be conveyed to secretary of the MDDS committee (mdds-mohfw@nic.in). (Reply to each of these queries within a one month time standard). f. Any modification would be notified on the website of MoHFW, NHSRC and the main portal of the standards. g. MoHFW would facilitate integration where requested. h. Exchange between state financed and central financed systems desirable- not mandatory.
  35. 35. Institutional Framework National Health Information Authority The Mandate • Testing & Certification • Accreditation • Compliance • Update • Upgrade • Identify gaps • Collect Feedback • Advocacy • Capacity Building • Incentive • Legislation • Publish • Disseminate • FAQs • Help lines MAINTAIN FACILITATE CERTIFYMANAGE MDDS Health Domain Standard
  36. 36. The Structure & Function The Mandate Policy Formulation Technical Group (4-5 Technical Architect) Functional Group (4-5 Health IT Professionals) Management Group (4-5 Health Mgmt Professionals Certification Group Core Groups National Health Information Authority Core Functions Health IT Forum Academic & Research Institutions
  37. 37. Concluding Remark • Solving the semantic barriers brings inter- operability much closer, but there would be still challenges to face. • EHR standards and MDDS publication is thus the first step of a long journey ….. not its final destination.
  38. 38. Thank You • We- in the MDDS committee- gratefully acknowledge the contributions of all our technical partners especially the work of UNITED HEALTH GROUP & TAURUS GLOCAL • We also acknowledge the contributions of technical experts in NIC and NHSRC who co-ordinated and contributed to this process. • And of many many others- with apologies for not naming them individually…..

×