• Regulation
  • India’s planning eHealth laws to tackle data breaches

    As cybercrime expands and eHealth becomes more affected and infected, India’s planning legislation for comprehensive civil and criminal remedies for eHealth data breaches. It’ll also set up an enforcement agency. Provisions are being drafted to deal with any breach of patients’ data.

    A report in the Times of India says the legislation will include a comprehensive legal framework to protect individual’s eHealth data, ownership of eHealth data, and health data standardisation for data collection, storage and exchange. African countries could benefit by monitoring India’s initiative as a comparator for their own eHealth legislation and regulation.

    Much of Africa’s eHealth in its infancy, so most African countries don’t have specific eHealth regulations. In 2012, a study for the European Space Agency (ESA), led by Greenfield Management Solutions (GMS), identified a 45% gap in Africa’s eHealth regulation compared to developed countries. Not much has changed since then. eHNA reported previously on Africa’s eHealth regulatory perspectives. Much more remains to be done, but it must not stifle innovation.

  • African eHealth needs data protection laws

    With much of Africa’s eHealth in its infancy it’s not surprising that most African countries don’t have specific eHealth regulations in place. In 2012, a study for the European Space Agency (ESA), led by Greenfield Management Solutions (GMS), identified a 45% gap in Africa’s eHealth regulation compared to developed countries. Not much has changed since then.

    One way to address this shortfall is for Africa to follow the EU's example in laying down common laws to help countries protect data as governments implement eHealth. A Liquid Telecom report, Cybersecurity and Data Protection, in ITWEB Africa, highlighted Uganda, Kenya, Tanzania, Ghana, Zimbabwe and South Africa as countries that are in the process of initiating data protection laws in Africa. eHNA reported recently that Angola has approved its data protection laws.

    Kenya’s Data Protection Bill 2013 aims to make it difficult for third parties to mine personal information without owners’ consents. Ghana’s Data Protection Act 2012 is facing slow enforcement. South Africa passed its legislation in September 2016. In Zimbabwe privacy is enshrined in the constitution. The only initiative to encompass most African countries is the African Union's Convention on Cyber Security and Personal Data Protection 2014, which  remains unratified by countries.

    "Some 53 African states came together to agree a legal framework to regulate various fields of ICT activity, ranging from e-transactions and personal data protection to cyber security. The convention is not however any kind of legally binding instrument, and requires that individual countries put its principles into their own statute book," the report said.

    Data protection laws for successful eHealth development are important. While regulation usually lags behind implementation, its key that eHealth’s regulated and regulations are passed in due time.

    Even though the continent’s efforts for general data protection  are fragmented and need further development, the report believes that  some countries are progressive. "There still needs to be more consensus on the meaning of key terms like 'consent', 'public interest' and 'legitimate grounds'. But there is hope that such details can be thrashed out and enshrined in a binding framework that both protects citizens and allows for healthy economic development," the report suggests.

    Data protection in healthcare is an important first step to protecting patients private medical data. While it’s a good foundation, more specific eHealth regulations are needed. An eHNA post sets out some of the challenges and has a link to an article setting out some eHealth regulation themes that for Africa’s eHealth that can go alongside privacy.

  • Angola moves data protection on

    In 2012, a study for the European Space Agency (ESA), led by Greenfield Management Solutions (GMS), identified the gap at about 45% behind in Africa’s eHealth regulation compared to developed countries. A year before, in 2011, Angola’s Data Protection Law No. 22/11 came into force in 2011. It provided for a Data Protection Authority (DPA) to be established.

    It defined personal data as 'any information, regardless of its nature or the media on which it is stored, relating to an identifiable natural person.' This generic definition is important for advancing regulation for the country’s eHealth.

    The GMS study for ESA identified the long lead time needed to convert eHealth regulatory principles into enabling legislation. The project’s workshops with selected sub-Saharan countries identified a realistic legislative process of about five years. Angola’s experience of moving its data protection initiative on shows that long time scales are needed.

    An article in Data Protection Leader says Angola’s President, His Excellency President José Eduardo dos Santos approved DPA framework in Decree No.214/16, on 10 October 2016, some five years after the Data Protection Act passed into law. The DPAs’ roles include receive notifications and fillings from data processes, support the Government to develop and establish data protection policy and represent the country in international data protection initiatives

    As Africa’s health systems develop their eHealth regulatory environments, it’s essential that realistic timetables are set. The ESA study and Angola’s data protection experience shows that progress won’t be rapid. It reinforces the need to start and sustain a momentum to close the gap.

  • Africa’s eHealth regulation needs a boost

    eHealth regulation in Africa trails well behind developed countries. A study for the European Space Agency (ESA) in 2012, led by Greenfield Management Solutions, identified the gap at about 45% points.

    Acfee’s Tom Jones writes in Data Protection Leader (DPL) “Not much has changed since 2012.”  Considerable challenges remain, including:

    eHealth regulation must compete with other eHealth prioritieseHealth regulatory bodies or organisations need establishing, requiring enacting legislation to define their delegated powers and resourcesThis kind of legislation can take several years to agree on with stakeholders and more time to find a place in countries’ legislative agendas for approvaleHealth regulations need enforcement and compliance reviews, which require resources and new skillsRecruiting, training and retaining smart compliance teams is essentialWith so many other competing priorities, it is likely that any recruitment and training developments of eHealth regulation will be modestPhased, long term, sustainable and achievable goals are needed.

    This seems like an insurmountable task. Tom Jones proposes a start point as setting specific eHealth regulation for privacy, building on the generic privacy legislation already in place in 88% of African countries. Because privacy requirements stretch across many aspects of eHealth, it provides a route into the choices for subsequent steps towards greater legislations. The article sets out examples of these.

    As eHealth keeps expanding with new initiatives, like Big Data and analytics, the eHealth regulation gap keeps widening. It’s essential that Africa’s health systems start to catch up.

  • EC’s mHealth privacy code can meet Africa’s regulation needs

    African countries recognise the need for privacy in eHealth. Many countries’ privacy regulations are for general data protection and may not be specific enough for all eHealth services. With mHealth being a major part of Africa’s eHealth, it seems to offer a good template to start to build up and apply eHealth regulations.

    The European Commission (EC) offers a helpful starting point. Its draft Code of Conduct on privacy for mobile health apps has been completed. It’s derived from data protection law, and awaiting formal approval. When it’s attained, app developers can volunteer their commitment to comply with the Code.

    Eleven questions comprise the issues dealt with by the Code:

    How should consent of app users be obtained, including valid, explicit consent from citizens to collect and use their dataWhat are the main principles that need adopting  before making an mHealth app available, including the purpose limitation, data minimisation, transparency, privacy by design, privacy by default and citizens’ rightsWhat information shall be provided to users before they can use any app, including a formal notice that identifies the app developer; describe the purpose of the data processing, how the data will be used and fits with products and services, guarantee fair processing; the precise categories of personal data that the app will process; whether personal data will be transferred from the user’s device, and if so, who to; users’ rights to access, correct and personal data; inform users that their app use is but needs their consent to permit personal data processing; provide contact information where users can ask question about data protection; and contain a link to a full privacy policy.  How long can data be retained, including acknowledging challenges to irreversibly anonymise health data when retention periods expireSecurity measures, including confidentiality, integrity and availability of the personal data processed by apps, and completing Privacy Impact Assessments (PIA)Can apps contain advertisements, including authorisation by users and having different approaches for advertising involving personal dataWhat’s needed before disclosing data to a third party for processing, including data used for scientific research, analytics or Big Data analysisCan personal data collected by apps be used for secondary purposes, including processing operations, needing agreements in place with third partiesWhere can gathered data be transferred to, including compliance with the rules for international data transfers and where gathered data can be transferred toWhat action’s needed if there’s a personal data breach including who to notifyHow can data be gathered from children, including parental consent, and especially when apps are for children’s use

    A set of questions are suggested for completing a PIA. They’re

    Which kinds of personal data will the app process?For which purposes will this data be processed?How have users’ consent been obtained to process their data for every type of use foreseen?Was someone designated to answer questions about the apps privacy requirements?Was the app developed in consultation with a healthcare professional to ensure that data is relevant for the app’s purposes and not misrepresented to users?Explain what’s been done to respect a set of security objectives, or explain why theyr’e not relevant:Principles of privacy by design and privacy by default:Data has been pseudonymised or anonymised wherever possibleAppropriate authorisation mechanisms have been built into the app to avoid unlawful access Effective encryption has been used to mitigate the risk of breachesIndependent system security audits have been consideredInform users when updated versions are availableBlocks all uses of old apps if the update is security critical  App has been developed using known guidelines on secure app development and secure software developmentApp has been tested using mock data before it’s available to real end usersIncidents affecting remotely stored data can be identified and addressedIf any personal data collected or processed by the app is transferred to a third party, has appropriate contractual guarantees about their obligations been obtained, including purpose limitations, security measures, and their liability.

    The Code is culmination of a wide range of contributions. It’s a very valuable contribution as best practice for attaining privacy in apps and for this aspect of mHealth regulation. App developers in Africa can enhance their products by showing how they’ve complied, even if countries haven’t incorporated them into eHealth regulations. These can follow on promptly if countries use the EC Code as their initial draft to prepare their bespoke versions.

  • eHealth algorithm and regulation let down cardiovascular patients

    When eHealth contributes to healthcare mission-critical activities, it’s vital it’s accurate, reliable, consistent and available. It seems that the UK’s NHS may have experienced a bit of a problem. 

    A report in The Times says “hundreds of thousands of patients could have been put at risk of heart attack and stroke or wrongly prescribed statins because of a software glitch.” It seems that an algorithm, the QRISK2 Calculaotr, wasn’t right. As a result, GPs had to contact all their patients assessed cardiovascular conditions using the SystemOne clinical programme since 2009, so over the last seven years. Some 2,700 GP surgeries may be affected. The Medicines and Healthcare Products Regulatory Agency (MRHA) has started an investigation.

    TPP, SystemOne’s owners, says that its solution contain over 40m patient records from more than 5,000 NHS organisations. These include more than 2,700 GP practices and 142 prisons. The system is verified by the NHS Health and Social Care Information Centre. 

    TPP and MHRA are collaborating to resolve the matter. It’s envisaged that it’ll take some time. The events reveal the need for effective eHealth regulation and compliance, a lesson for African countries. As eHealth moves further into using algorithms to support clinical activities, the more regulation and compliance reviews are needed. Effective eHealth regulation is costly. So’s the lack of regulation.

  • mHealth growth outstripping regulation isn't good

    Huge mHealth growth over recent years has left regulation chugging along in the inside lane. A team from the Netherland’s National Institute for Public Health and the Environment (RIVM) has analysed the difference and found a need to catch up.

    Its findings are in the Journal for Medical Internet Research (JMIR). From about 5,80 mHealth apps in 2011, there were over 23,000 in 2013 in the iTunes store, but not much’s known about their uses, effectiveness and risks. The study focused on an inventory of 116 apps and other tools used with medication. Diabetic patients were asked to complete a questionnaire about their apps’ experiences.

    Many apps mainly offer simple functionalities. The most experienced users’ benefits were for regulating blood glucose levels. A minority of apps for medication use have potentially high risks. For some apps, it’s unclear whether and how personal data are stored.

    A small subset of tools might involve relatively high risks. For the larger group of non-medical devices, risks are lower, but there’s still a mismatch between the enormous availability and low levels of regulation. Users and nonusers said there are issues with the overall quality of apps, such as ease of use, completeness and good functionalities.

    Important mHealth benefits for users, such as better health and self-reliance, arise from regulating blood glucose levels, so improving reliability and quality is likely to offer more benefits. Increased mHealth awareness’s important too. 

    A big challenge remains. There’s still a mismatch between the enormous availability and low levels of regulation. Africa has a regulation deficit compared to developed countries, and as its mHealth expands, catching up will be more demanding. Starting now’s a good option.


    Image from DigitalHealth.net

  • A regulation guide helps mHealth developers

    As more mHealth initiatives build up their momentum, it’s important that they comply consistently with countries’ regulations. Accessing and understanding these can be a bit like trudging through treacle. In the USA, the Federal Trade Commission (FTC) has produced a simple online guide and questionnaire that developers can use to work their way through the regulations they need. It’s a joint project with the Department of Health and Human Services, the Office of the National Coordinator for Health Information Technology (ONC), the Office for Civil Rights (OCR) and the Food and Drug Administration (FDA).

    It’s an initiative that Africa’s health systems can adopt and develop, but it’s clearly a considerable undertaking needing extensive engagement. With fewer mHealth regulations than the USA, an equivalent service should be less demanding to produce. Acfee has a regulation database and model that can provide a start.

    There are three sections:

    What are the laws? Which laws apply to developers’ mHealth apps? Glossary 

    For Africa’s health systems, the laws may include data protection acts, telecommunications regulations and generic rights of citizens. Health regulations are relevant too. Acfee’s eHealth regulation database shows that many African countries have specific eHealth regulations, so an online checklist will need to be updated as eHealth regulations are developed and applied.

    There are a set of questions needed to identify applicable laws. They include: 

    Will the app create, receive, maintain, or transmit identifiable health information? Is the developer a healthcare provider or health plan? Do consumers need a prescription to access the app? Is the app being developed on behalf of hospitals, doctors office, health insurer, or health plan’s wellness programme? Is the app intended for diagnosing diseases or other conditions, or curing, mitigating, treating or preventing diseases? Does the app pose minimal risk to users, such as: Managing their diseases or conditions without providing specific treatment suggestions Providing users with simple tools to organise and track their health information Providing easy access to information about health conditions or treatments Helping users document, show or communicate potential medical conditions to healthcare providers automating simple tasks for healthcare providers Enabling users or providers to interact with EHRs Transferring, storing, converting format or displaying medical device data? Is your app a mobile medical app intended for: Use as an accessory to a regulated medical device Transforming a mobile platform into a regulated medical device Performing sophisticated analyses or interpreting data from another medical Does the app offer health records directly to consumers or does it interact with, or offer services to, someone who or an entity that does? 

    Yes or no answers to each question link directly to a list of the laws and regulations that developers need to conform to. It’s very easy to use. A glossary offers more information. It’s an ideal template for Africa’s health systems to use to begin to move their eHealth and mHealth regulations on.

  • Does Africa need telemedicine regulations?

    Clarity on the place of telemedicine isn’t always clear. Some doctors are content to use it without specific regulations, others want clarity on how it fits with the traditional patient and doctor relationships and encounters.

    The USA’s District of Columbia has started formal consultation on telemedicine regulations. There are 14. They may help Africa’s telemedicine to move into a regulated environment. A generalised summary’s:

    To use telemedicine, a license to practice medicine’s required, but with some exceptions in existing laws and regulations, and a requirement to comply with regulations in the jurisdictions where the telemedicine provider’s and patients are physically located Doctors’ medical decisions using telemedicine must adhere to the same standards of care as decision in face to face encounters with patients Patient evaluations are needed that meet the requirements in existing standards before providing recommendations or making treatment decisions for patients except when performing interpretive services Doctors must ensure that interpretive services do not result in clinically significant loss of data from image acquisition through transmission to final image display Doctors practicing telemedicine shall: Obtain and document patient consent, except for interpretive services Create and maintain adequate medical records Follow requirements of existing laws and regulations for confidentiality of medical records and disclosure of medical records Adhere to other existing relevant laws, requirements and prohibitions Doctors shall perform patient evaluations to establish diagnoses and identify underlying conditions or contraindications to recommended treatment options before providing treatment or prescribing medication Licensed doctors may rely on patient evaluations performed by another licensed doctor if the former is providing cover for the latter If doctor-patient relationships don’t include prior in-person, face-to-face interactions with patients, doctors shall use real-time auditory communications or real-time visual and auditory communications to allow a free exchange of protected health information between patients and the doctors performing the patient evaluation Licensed telemedicine practitioners shall have the current, minimal technological capabilities to meet all standard of care requirements in order to use telemedicine to deliver services or treatment Adequate security measures shall be implemented to ensure that all patient communications, recordings and records remain confidential Written policies and procedures shall be maintained when using email for doctor-patient communications, and these shall be evaluated periodically to make sure they are up to date in addressing: Privacy, to assure confidentiality and integrity of patient-identifiable information Responsibilities of all health care personnel, including doctors, who process messages Hours of operation and availability Types of transactions permitted electronically Required patient information to be included in communications, such as patients’ names, identification numbers and types of transactions Archival and retrieval of patient records Quality oversight mechanisms All relevant patient-doctor emails and other patient-related electronic communications shall be stored and filed in patients’ medical records Patients shall be informed of alternate forms of communications between them and doctors for urgent matters All licensees shall be subject to the requirements of health and healthcare laws and regulations.

    It’s a start for Africa’s telemedicine regulations where health systems haven’t started down this road. Like the District of Columbia recognises, consultation with the medical profession’s the vital first step. Other stakeholders can make contributions too. Having agreed telemedicine regulations, a follow-up’s to ensure effective implantation and compliance.

  • L'utilisabilite de l'eHealth en l'Afrique est-elle a risque?

    Alors que l'Afrique progresse vers l'utilisation des dossiers de santé électroniques (EHR, de Electronic Health Record), la réglementation, la convivialité et les approvisionnement doivent converger. Ergonomie est une composante essentielle des avantages, et la réglementation est essentielle à la mise en place des EHR et des autres normes de convivialité de la télésanté et la certification des fournisseurs. L'approvisionnement sera, lorsque ceux-ci sont appliqués. Les systèmes de santé africains ont quelques défis.

    Leurs règlements en matière de télésanté sont bien après les bonnes pratiques. Une étude sur la régulation de la télésanté dans les pays d’Afrique sub-saharienne par «Solutions de Gestion Greenfield» d'Afrique du Sud a montré que les réglementations spécifiques en matière de télésanté sont minimes, avec le recours à des règlements généraux tels que la protection des données et de la réglementation des télécommunications. Ce statut ne permet pas de fixer des normes UCD (Design Centré sur l'Utilisateur) pour une facilité d'utilisation à appliquer par les fournisseurs d'application de télésanté. Deux sources principales de ces-ci sont un générique et un pour les EHR.

    La norme ISO 9241-210: 2010 est générique. Il dispose de six principes de conception de base de la convivialité où le design est:

    Basé sur une compréhension explicite des utilisateurs, des tâches et des environnements, Les utilisateurs sont impliqués tout au long de la conception et le développement, Une évaluation conduite et affiné par l'utilisateur, Un processus itératif, Aborde toute l'expérience des utilisateurs, Traitées par des équipes pluridisciplinaires avec une gamme appropriée de compétences et de perspectives.

    Les Etats-Unis ont des exigences spécifiques. C'est l'Institut National des Standards et Technologies a adopté le NISTIR 7741, Guide NIST des approches de processus pour améliorer la convivialité des dossiers de santé électroniques. Ses principes sont les suivants:

    Comprendre les besoins des utilisateurs, des flux de travail et les environnements de travail, Engager à temps les utilisateurs et souvent, Définir des objectifs de performance de l'utilisateur, Concevoir l'interface utilisateur à partir de principes de comportement humain connus et des modèles d'interface utilisateur familière, Des tests de conduite d'utilisabilité pour mesurer à quel point l'interface répond aux besoins de l'utilisateur, Adapter la conception et les tests de façon itérative avec les utilisateurs jusqu'à l'atteinte des rendements objectifs.

    Il dispose de six types de conformité:

    0 - incomplète, donc incapable de mener à bien le processus

    1 - effectuée, quand les individus effectuent le processus

    2 - gérée, quand les exigences de qualité, de temps et de ressources pour le processus est connu et contrôlé

    3 - établie, quand le processus est exécuté comme prévu par une organisation, et les ressources sont définis

    4 - prévisible, quand la performance du processus est dans les limites des ressources et de qualité prévus

    5 - optimisée, quand une organisation peut adapter le processus de manière fiable à des exigences particulières.

    En incluant ces normes d'utilisabilité dans les règlementations de télésanté, les systèmes de santé peuvent s'attendre à des fournisseurs se conformant aux bonnes pratiques, conduisant ainsi à des réalisations bénéfiques. Les systèmes de santé peuvent également vérifier dans quelle mesure les fournisseurs respectent les normes. Ceci est la plus-value.

    Une équipe dirigée par Dr Raj M. Ratwani de MedStar Health, Washington, DC, a écrit une lettre de recherche pour le Journal de l'American Medical Association (JAMA). Il dit que de nombreux fournisseurs EHR ne sont pas conformes aux normes d'utilisabilité. C'est une découverte importante parce que beaucoup de EHR ont une faible utilisabilité.

    L'équipe a examiné la documentation de 41 des 50 fournisseurs certifiés:

    34% a omis d'indiquer leur processus UCD, 46% ont utilisé une norme UCD d'industrie, 15% ont utilisé un processus UCD développé en interne, 63% ont utilisé moins de la norme de 15 participants, 22% ont utilisé au moins 15 participants ayant des connaissances cliniques, Un fournisseur n'a utilisé aucun participant avec des connaissances cliniques, 17% n'ont pas utilisé de médecins comme participants, 5% ont utilisé leurs propres employés, 12% manquait suffisamment de détails pour déterminer si les médecins ont participé, 51% n'a pas fourni les détails démographiques nécessaires.

    Cette mauvaise observance est produite dans un système très réglementé, et a été révélé. Avec les pays africains à réglementation limitée, ils sont plus vulnérables à des limitations d'utilisabilité d'application de télésanté, conduisant à une réduction des prestations et le gaspillage des ressources. La prochaine étape est simple: renforcement de la réglementation de la télésanté pour les marchés.


    See article in english