• Standards
  • Kenya’s mHealth standards are clear on compliance

    mHealth standards and guidelines are essential, but have to be applied. Like all regulations, effective compliance’s essential. Kenya Standards and Guidelines for mHealth Systems sets three main part of the Ministry of Health approach. They’re:

    Commitment at a senior level is a requirement for stakeholders, including an accountable resource either as an officer or managerImplementation that identifies the resources, including a person, needed for the design, development, implementation and monitoring stages and documenting compliance levels Audit, with a person assigned to provide an objective review of documentation and the compliance process to provide feedback and recommendations directly to management, especially for corrective action needed where compliance is weak or missing. 

    There’s a big stick too. Fines and penalties are part of a range of measures to encourage compliance. Building on Kenya National eHealth Policy 2016-2030, the mHealth standards are a huge step forward for eHealth regulation, not just for Kenya, but across Africa too.

  • How can Africa innovate with Unique Patient Identifiers?

    Unique Patient Identifiers (UPI) are both essential and demanding to achieve. They’re harder to use when data’s transferred and shared between organisations. An article from the American Health Information Management Association (AHIMA) proposes innovation with UPIs propriety to vendors and customers as part of the solution. For African health systems, it may improve the current position until national UPIs are in place.

    US provider organisations and payers are innovating with propriety UPIs. A common theme’s dealing with real time or batch queries held by third parties, such as credit agencies. These already have UPIs for their commercial activities. It suggests they offer value to health organisations because commercial entities frequently update and constantly maintain their data, providing current demographics for data warehouses, population health management and illness prevention.

    UPI innovation must be integrated with eHealth governance, which need developing in African health systems. Through eHealth governance, UPI innovation can engage with stakeholders such as:

    Governance teamsProfessional bodiesPatient access and registration staffHealth information management teamsICT teamsData users, such as care coordinators and health analytics teams.

    Their roles can extend to strategic information governance and how innovation and success will be applied. Mitigating risks is another role they can participate in.

    A set of generic questions can help to define UPI innovation:

    Who’s responsible for identifiers’ integrity, especially new identifier created by innovation?When existing data’s augmented with new external data, how is the new data integrated, and what is its lifecycle of managed?What are acceptable uses for the identifiers set by legal and regulatory requirements for UPIs, privacy and compliance?How can organisations incorporate UPI technology with human data stewardship to ensure a compliance and governance?How are discussions and findings from UPI innovation relayed to eHealth governance?How can discussions be for ICT, and people and process supporting eHealth governance?Should innovation deal with data creation for patient access or registration, data governance through procedures, processes and data fields standardisation, or both?How can a sample database be built to support proof of concept and technology?How can enough data be included in UPI innovation projects for rigorous, reliable testing, such as 100,000 records?How can UPI data goals be integrated into data governance programmes?

    AHIMA’s article says organisations and healthcare professionals are cautious in applying innovation to the long-standing UPI challenge. Mismatching records can have profound, adverse effects, so reluctance is reasonable. Despite these anxieties, innovation can still proceed, provided it’s based on a rigorous risk assessment, impact probability, costs and benefits.

    UPI innovation creates two activities for Africa’s health systems. One’s setting up their UPIs. The other is constant, managed innovation with UPIs.

  • IHE updates cardiology, IT infrastructure and radiology frameworks

    It is important that Africa’s health systems and informatics teams contribute to Integrating the Health Enterprise (IHE) updates. They are opportunities to help to shape eHealth’s essential building blocks and how they change.

    IHE has put out three framework updates:

    Cardiology Procedure Note (CPN) Rev. 1.1IT Infrastructure Technical Framework SupplementsRadiology volumes 1 to 4.

    The IHE Cardiology Technical Committee says trials began on 4 August 2017. They may be available for testing at IHE Connectathons. Comments on the changes can be submitted at any time.

    The IHE IT Infrastructure Technical Committee has published supplements for trial implementation, also from 4 August 2017. These profiles may be tested at IHE Connectathons and comments are invited at any time. They deal with:

    Mobile Care Services Discovery (mCSD) Rev. 1.1Mobile Cross-Enterprise Document Data Element Extraction (mXDE) Rev. 1.1Non-patient File Sharing (NPFSm) Rev. 1.1.

    Four updated Radiology Technical Framework (RADTF) volumes deal with:

    Volume 1 (RAD TF-1) Integration ProfilesVolume 2 (RAD TF-2) TransactionsVolume 3 (RAD TF-3) Transactions (continued)Volume 4 (RAD TF-4) National Extensions.

    Like the cardiology and IT infrastructure updates, comments can be submitted at any time and profiles may be tested at subsequent IHE Connectathons.

  • 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 frameworkProtection of privacy and confidentialityManaging disclosures of health informationSource code and application ownership.

    Governance has four main parts:

    SecurityValidationAccountabilityOwnership.

    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:

    PlanningLandscape analysisLocal and national health priorities and needsTarget audience analysisProject 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 developmentDesign, including technology, content, workflow impact and usability, a critical requirement for benefits realisationTechnology decisionsCreating message contentTesting message contentPrototype 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 targetsBenefits realisation models that follow on from project management and set baselines for the health benefits included in the standard’s M&E sectionApplying WHO’s Monitoring and Evaluating Digital Health Interventions A practical guide to conducting research and assessment accessible from eHNA’s ResourcesDistinguishing 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 SMSsStandards for text messages, including device selections, risk assessments, development practices and trainingPHI security guidelinesRisk 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 responsibilitiesGuidelines for using eHealth and ICT to provide healthcareWhat 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 choiceAuthenticating ePrescriptionsDelivering ePrescribed drugs and medications and the role of pharmacistsePrescribing 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 evaluationDynamic, to recognise and comprehend data changes in systems over timePragmatic, including modest AISemanticSyntactic and workflow integrationTechnical and integratedNone, 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 gatheringSystems analysisSystems designDevelopment and implementationSystems testingOperations and maintenanceSupportPost-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 manualDeveloper’s guideUser manual.

    Four requirements for data validation are included:

    First order, ensure valid data formats and values and prevent obvious data entry errorsSecond order, historical data comparisons for alerts for changesThird order assess data for consistency in specific forms and indicator setsFourth 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: 

    Limiting undue burden by leveraging the use of existing reporting frameworksStandards as the means, with the standards measured aligned to use cases critical to advancing IOp and better information exchangeIncluding all relevant stakeholders, including the Centers for Medicare and Medicaid Services (CMS) and the Centers for Disease Control and Prevention (CDC).

    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 systemsEnsure that data exchange identifies patients with 100% certaintyMake 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.