• Standards
  • Kenya’s mHealth standards set out governance and policy rules

    Leadership’s seen as an underpinning component of mHealth governance and policy. Kenya Standards and Guidelines for mHealth Systems sets out the Ministry of Health approach to framework of strategies, plans, budgets, governance and policy.

    Kenya already has a governance framework. It integrates three stakeholder types, policy, suppliers and users. It fits into its institutional governance framework described in Kenya National eHealth Policy 2016 to 2030. Its mHealth governance arrangements fit within its three main policy stakeholder parts of policy, suppliers and users. Each one sets out stakeholders’ roles and responsibilities.

    Its regulation standards extend across:

    • A certification framework
    • Protection of privacy and confidentiality
    • Managing disclosures of health information
    • Source code and application ownership.

    Governance has four main parts:

    • Security
    • Validation
    • Accountability
    • Ownership.

    These are huge steps forward for all Africa’s eHealth. A possible trajectory for eHealth governance may be towards the standards released by the American Health Information Management Association (AHIMA). An eHNA post summarised these. COBIT 5 is an international for ICT governance in all economic sectors. Published by ISACA, It’s been adopted by AeHIN. As an extremely sophisticated governance model, it shows a possible destination of Africa’s eHealth governance.

  • Kenya’s mHealth standards set an implementation cycle

    Rigorous implementation standards are set out in Kenya Standards and Guidelines for mHealth Systems. The extensive content in the Ministry of Health report extends from planning to scaling up. The steps are:

    • Planning
    • Landscape analysis
    • Local and national health priorities and needs
    • Target audience analysis
    • Project management

    o   People’s roles, responsibilities, teams, communication and relationships

    o   Systems, from implementation to M&E

    o   Defined policies and procedures for data

    • Partnership development
    • Design, including technology, content, workflow impact and usability, a critical requirement for benefits realisation
    • Technology decisions
    • Creating message content
    • Testing message content
    • Prototype and usability content

    o   Systems launch, including, Beta version process and creating user demand, including incentives and benefits

    • M&E, including needs assessments, monitoring systems and outcomes

    o   mHealth system, including the WHO methodology mHealth Evaluation Reporting and Assessment (mERA)

    o   Compliance with the mHealth standards and guidelines

    • Scaling up activities, including using the WHO model for mHealth Assessment and Planning for Scale (MAPS) and its six steps of groundwork, partnerships, financial health, technology and architecture, operations and M&E.

    Some implementation components are not emphasised explicitly in the standards and guidelines:

    • Business cases, such as the Five Case Model, needed to identify optimal mHealth options for decision takers before mHealth projects begin and setting explicit probable, not potential, socio-economic goals measured by cost benefits or cost effectiveness, and affordability requirements, an essential component of sustainability and setting M&E baselines and performance targets
    • Benefits realisation models that follow on from project management and set baselines for the health benefits included in the standard’s M&E section
    • Applying WHO’s Monitoring and Evaluating Digital Health Interventions A practical guide to conducting research and assessment accessible from eHNA’s Resources
    • Distinguishing between mHealth’s economic and financial components, described in Defining a staged-based process for economic and financial evaluations of mHealth programs, also accessible from eHNA’s Resources.

    These added themes contribute to the standard’s goals of “Well thought-out planning … knowledgeable people … M&E.” It shows how demanding successful mHealth can be.

  • Kenya’s mHealth standards set SMS and ePrescribing practices

    Using SMS for health and healthcare’s an expanding initiative in Africa. Kenya’s Ministry of Health has set out a rigorous set of standards for it, and ePrescribing, in Kenya Standards and Guidelines for mHealth Systems. 

    As an effective communication tool for health in low-income countries, SMS need regulation and cyber-security standards that minimise the risk of privacy and confidentiality breaches. This extends across several activities. Kenya’s standards include:

    • Risks of Personal Health Information (PHI) in SMSs
    • Standards for text messages, including device selections, risk assessments, development practices and training
    • PHI security guidelines
    • Risk management strategy, including password confidentiality and encryption.

    Standards for telephone and eConusltations deal with devices such as Interactive Voice and Video and Response (IVVR), mobile phones, teleconferencing, Voice over Internet Protocol (VoIP. It includes SMSs too. The themes are:

    • Good medical practices, duties and responsibilities
    • Guidelines for using eHealth and ICT to provide healthcare
    • What to do in emergency situations. 

    ePrescribing extends from completing prescriptions, through delivery to pharmcists and on to dispensing to patients. Its goals include better quality healthcare, patient safety, accuracy and continuing care. The standards deal with:

    • How to use ePrescribing, including patient choice
    • Authenticating ePrescriptions
    • Delivering ePrescribed drugs and medications and the role of pharmacists
    • ePrescribing data sets that include:

    o   Minimum patient demographics

    o   Prescription identifiers

    o   Product identification.

    While addressing current eHealth requirements, these standards lay a foundation for eHealth’s future scale and direction. It’s an opportunity to move eHealth regulation closer to project implementations, especially for ePrescribing.

  • Kenya’s mHealth standards are strong on IOp

    Kenya’s Ministry of Health has set a solid foundation for its next step in eHealth regulation and good practices. The second main section in Kenya Standards and Guidelines for mHealth Systems deals with information exchange and Interoperability (IOp). It has a seven stage model of IOp maturity, including level 0 for no maturity and three conventional IOp classifications of technical, syntactic and semantic. They’re:

    • Conceptual, enabling other engineers to understand documentation and evaluation
    • Dynamic, to recognise and comprehend data changes in systems over time
    • Pragmatic, including modest AI
    • Semantic
    • Syntactic and workflow integration
    • Technical and integrated
    • None, so can be ignored.

    They combine into three categories, integration, IOp and composability for maximum interoperation. It’s a requirement that all Kenya’s mHealth complies with its IOp standards. These include Health Level (HL)7 version 3 for clinical messaging and International Classification of Diseases (ICD) 10, Systematized Nomenclature of Medicine (SNOMED) for coding, Logical Observation Identifiers Names and Codes (LOINC) and Rx Norm for pharmacies.

    Developers have to provide Standards for Applications Programming Interfaces (API) to define how their mHealth interacts with other systems. It fits into a Fast Health Interoperability Resources (FHIR) architecture. It complies with Integrating the Healthcare Enterprise (IHE) and HL7 standards

    While these apply to health and healthcare data, Kenya’s standards apply to social health determinants too. It’s an indicator of the breadth of its approach.

  • Kenya’s mHealth standards for documentation add clarity

    Covering a wide range of mHealth standards, Kenya’s Ministry of Health has set a firm foundation to step up its wide eHealth regulation and good practices. The first main section in Kenya Standards and Guidelines for mHealth Systems deals with development and functions. It’s comprehensive.

    Software development has to comply with a set of phases: 

    • Requirement gathering
    • Systems analysis
    • Systems design
    • Development and implementation
    • Systems testing
    • Operations and maintenance
    • Support
    • Post-implementation M&E.

    Documentation needed for these includes:

    ·       Systems Requirement Specification (SRS)

    ·       Software design documents, depending on the mHealth software design methodology, will include some of:

    o   Unified Modelling Language (UML) diagrams

    o   Data Flow Diagrams (DFD)

    o   Flow charts

    o   Entity relationship diagrams

    ·       Implementation plan, including:

    o   Implementation manual

    o   Training and capacity building manual

    ·       Test plans

    ·       Deployment procedures

    ·       M&E criteria.

    Three other required documents are:

    • Technical manual
    • Developer’s guide
    • User manual.

    Four requirements for data validation are included:

    • First order, ensure valid data formats and values and prevent obvious data entry errors
    • Second order, historical data comparisons for alerts for changes
    • Third order assess data for consistency in specific forms and indicator sets
    • Fourth order, assess statistical outliers for validity. 

    These examples show the range and rigour of Kenya’s mHealth standards. They fit all types of eHealth too. It’s a considerable benchmark for all Africa’s health systems.

  • US eHealth IOp should focus on big impacts

    Interoperability (IOp) in eHealth isn’t an absolute state. Measuring it isn’t either. Sir William Osler, a Canadian doctor and one of four founding professors of Johns Hopkins Hospital, didn’t need to bother with eHealth IOp, but hinted at it in strategy when he said “In seeking absolute truth we aim at the unattainable and must be content with broken portions.”

    Challenges are how much, and which IOp measurement will achieve contentment without breaking it. An article in Fierce Health provide some indication. It sets out responses from five US organisations to the Office of the National Coordinator (ONC) report in the Proposed Interoperability Standards Measurement Framework, reported by eHNA in May.

    It has two main themes.  One’s measuring standards implementation. The other’s how end users can refine and customise standards to meet their needs. Most groups expressed some trepidation that new standards would result in an undue burden for providers. They want the ONC to focus on measurement areas with the biggest impact. Their advice is directly relevant for Africa’s IOp plans.

    The American Medical Informatics Association (AIMIA) supported the ONC’s framework in its response. It also asked the ONC to target “high-value standards” that offer the biggest impact. Specific requirements are functionalities for accessing drug databases and transmitting laboratory data. It wants the measurement framework to be automated too, so easier reporting mechanisms translate to higher participation.

    A combination of support and caution was part of the Health Information Management and Systems Society (HIMSS) contribution. It offers three main themes: 

    A sub group of HIMSS, the Electronic Health Record Association (EHRA) suggested a combination of standardised approaches with non-standard methods. It’s a focus on use cases with the biggest impact. It emphasised the potential burdens too.

    The College for Health Information Management Executives (CHIME) highlighted patient matching as one of the biggest IOp barriers. It says measurement standards are premature, and wants the ONC to:

    • Develop standards for seamless communication between ICT systems
    • Ensure that data exchange identifies patients with 100% certainty
    • Make data exchange usable for clinicians before tackling IOp standards.

    CHIME proposed that if the measurement framework’s implemented, the ONC should work with stakeholders to prioritise cases and develop a granular set of standards.

    Health IT Now, a coalition of patient groups, healthcare organisations, employers and payers, recognises that measuring IOP’s necessary, and said a narrow focus on successful data transmissions devalue improvements in using data to improve care and defer the capability of health systems to exchange information. It wants collaboration with patients and patient advocates and private sector organisations that can contribute to identifying, developing, and deploying IOp standards for better information systems.

    These perspectives can inform Africa’s eHealth development. IOp and its choices are seldom off the eHealth agenda.

  • Kenya’s setting up new mHealth legislation

    Africa’s eHealth legislation and regulation needs considerable developed. Kenya’s stepping it up, eHealth experts have welcomed proposed eHealth legislation, including the Health Act 2017 and the Kenya Standard and Guidelines for mHealth Systems. They see the legislation as facilitating Interoperability (IOp) between private and public healthcare, and as guidelines to move wider eHealth on says an article in ITWEB Africa.

    The Health Act 2017 says within three years of its operation, the Ministry of Health (MoH) will implement management information banks. They’ll include an IOp framework for data interchange and security to improve personal health information management.

    Tony Wood, Managing Director at My Dawa, an online service for ordering prescription and wellness products, said he welcomed legislation that builds the eHealth ecosystem. "With everything, as you look at the world, technology is moving faster than regulation, governments and policy. More can now be done on how these are implemented going forward. I hope they are going to be implemented through open consultation where the public and private sector are working together." This seems like the next step.

    The 66-page guidelines are wide ranging. They set out definitions and extend across mHealth implantation, standards, governance and policy. The proposed legislation’s scheduled for debate in the national assembly. It’s a crucial stepping stone implementing successful and sustainable mHealth and wider eHealth.

  • Now's your chance to be certified in SNOMED CT

    Terminology standards are part of health informatics’ core. Opportunities in Africa to acquire the skills are limited, both in access to universities and affordability. Now, there’s a chance to use eLearning to gain a certificate in the health terminology standard Systematized Nomenclature of Medicine--Clinical Terms, commonly known as SNOMED CT.

    IHTSDO, SNOMED CT’s owner, has recently launched their eLearning platform. It provides online courses, tutorials and other materials designed to enable you to learn more about SNOMED CT. They also offer completion certificates to people who pass course assessments. 

    At this stage, courses available are the SNOMED CT Foundation course and SNOMED CT Implementation modules. The foundation course is self-paced. You can start shortly after you register. Both courses are free, and provide a valuable opportunity for health informatics students and leaders to learn and share knowledge about an important eHealth building block.

    To find out more about these education services please visit the E-Learning Overview. For access to courses, tutorials and other educational materials go to the SNOMED CT E-Learning Server. If you have any questions, or want more specific information about the opportunity and how you make the most of it, you can email IHTSDO at info@ihtsdo.org.

    This’s a big opportunity for Africa’s eHealth. If you’re taking it up, please let eHNA know about your experiences so you can share it.

  • IHE, AHIMA and HIMSS promote better eHealth standards

    Integrated Health Enterprise (EHI) with the American Health Information Management Association (AHIMA) and the Healthcare Information and Management Systems Society (HIMSS) have released a robust and thorough white paper on health ICT and information infrastructure, security and Interoperability (IOp). It includes eight capabilities needed for information protection:

    1. Ensure appropriate levels of protection from breach, corruption and loss of private and confidential information classified and essential to business continuity or other reasons
    2. Consistently apply and enforce levels of protection to information from the moment it’s created until the moment it reaches or exceeds its retention period and is appropriately disposed, including adherence to security, privacy and confidentiality rules, regulations and policies when determining a method for the final disposition of information, regardless of source or media, and whether the disposition is archival, transfer to another organisation, preservation for permanent storage or destruction
    3. Establish an audit programme that defines a clear process for verifying whether sensitive secure information is being handled in accordance with organisations’ policies and procedures
    4. Manage and balance compliance with the varying degrees of protection, mandated by laws, regulations, and organisations’ information policies
    5. Provide security, business continuity, and disaster recovery processes that ensure continued operation and protection during and after periods of failure or disruption
    6. Assign and manage appropriate levels of information access and security clearance to all members of the workforce and other authorised parties relevant to their roles or duties
    7. Maintain appropriate security safeguards, clearly defined and enforced by organisations’ policies that protect electronic information from being inappropriately viewed, emailed, downloaded, uploaded or proliferated intentionally or inadvertently
    8. Provide physical security safeguards for computing and access devices and equipment containing organisations’ private, secret or confidential information or intellectual property.

    It identifies numerous gaps in both Health Information Management (HIM) practices and standards development. Fixing these needs compliance with recommendations for HIM professionals and Standards Development Organisations (SDO):

    • Standardise and harmonise the scope and operations of organisations’ information committees in line with the information governance principles
    • Harmonise and standardise Committees’ policies across healthcare organisations
    • Develop a template of organizational policy related to documentation development and management
    • Define a standardised set of documentation for episodes of care
    • Collect applicable documents that are available for complete episodes of care
    • Define policies on open and closed records and the processes and timeliness of record completion, including finalising definitions on open records such as incomplete, lost, delinquent and cancelled
    • Define policy that outlines how clinicians are notified of open and closed records when:
      • Procedures are ordered but not performed
      • Documentation components are missing or signatures are missing
    • Define a minimum set of content to be analysed for timeliness and completeness of legal records
    • Define data provenance of content and source for metadata tags such as the who, what, when, where, why
    • Designate HIM representatives to participate at HL7 Working Groups including:
      • HL7 Community-based Collaborative Care (CBCC) Work Group
      • Review the Patient Friendly Consent Directive standard ballot.

    While information security is close to an absolute state, IOp isn’t, The big IOp challenge for Africa’s eHealth’s how much IOp’s enough?

  • Accrediting suppliers for procurement isn't enough

    An important part of eHealth regulation’s accrediting suppliers. An aim’s to be sure that functionalities and standards in supplier’s solutions match health system’s information requirements. It’s a good idea to match the two perspectives before procurement. It also avoids wasting time where bidders don’t comply, but it’s not enough.

    A USA Senator, Dr Bill Cassidy and Sheldon Whitehouse, don’t think accreditation’s good enough. Whitehouse has said ”After a health IT product is certified for use, there’s no way to ensure that it continues to deliver as promised for doctors and patients, and no way to easily compare one product to another,” so, they’re proposing legislation, the Trust Act, to improve it. These are important developments for Africa’s eHealth regulation and procurement.

    It aims to make health IT suppliers accountable for their systems’ performances in:

    • Security
    • Usability
    • Interoperability (IOp).

    It’ll achieve this by establishing a Health IT Rating System so consumers can compare certified health IT products on the three criteria. The bill also establishes a process to collect and verify confidential feedback from healthcare providers, patients, and other users on usability, security and IOP.

    Other measures include:

    • Making information, such as summaries, screen shots, or video demonstrations, showing how certified health information technology meets certification requirements publicly available
    • Requiring the certification programme establish that health IT products meet applicable security requirements, incorporate user-centred design, and achieve IOP consistent with the reporting criteria used in the Health IT Rating Programme
    • Requiring health IT vendors to attest that they don’t engage in specified information blocking, such as nondisclosure clauses in their contracts, as a condition of certification and maintenance of certification
    • Authorises ways to investigate claims of information blocking and assess civil monetary penalties on anyone, or entity, found to have committed information blocking.

    These enhanced requirements should enable health ministries and other users to track the performance of their health IT providers beyond the procurement stage and into routine operation. It’s an important activity for Africa’s health systems and can step up their market power in regulation and procurement.