• Interoperability
  • IOp for clinical data’s vital to eHealth success

    These days, healthcare professionals need reliable, available clinical data. At eHealth ALIVE’s masterclasses, Shelly Lipon, from the International Health Terminology Standards Development Organisation (IHTSDO) and the Systematized Nomenclature of Medicine–Clinical Terms (SNOMED-CT) initiative, unpacked Interoperability (IOp) and profiling terminologies.

    SNOMED-CT’s the world’s most comprehensive multilingual clinical terminology. It contains scientifically validated clinical content and maps to other international standards. In eHealth, it supports high quality clinical content in EHRs and has an increasing number of tools and implementations. It’s not surprising it’s used in more than 50 countries.

    Its clinical terms are comprehensive as a SNOMED concept. A comprehensive clinical scope reduces need for several coding systems, that also enables queries that span across numerous multiple disciplines and clinical areas, such as test results, diagnosis, medication, devices, procedures and organisms. It’s multilingual to, so can localise national, regional and dialect use. This’s matched by a facility that links different ways of saying the same thing by a common code.

    The common reference terminology facilitates integration of clinical data from many sources that use different code systems or free text. It means that it can provide consistent representations of meaning for retrieval, processing and communication. Computable definitions of meaning allows meaning-based retrieval of clinical relevant facts that help to define relationships, support powerful querying, reporting and linking knowledge.

    Using discharge summaries as an example, Shelly summarise the range of information needed. It includes diagnoses, procedures, medications, social circumstances and follow-up appointments. These are in a combined context of current problems, past medical histories and future contexts. The data can come from single or several systems.

    A data model for discharge summaries includes the data’s form, and the form it’s transferred in. Data’s recorded in text and clinical terminology codes. Terminologies used are classifications of data recorded as summaries of episodes of care, or data used for real-time recording. It’s transferred  as message structures that can include coded data only, original text only or a mixture of coded and original text. An example of SNOMED-CT’s codes is:

    Currently, SNOMED-CT isn’t used widely across Africa. Examples are in supporting HIV/AIDS services. As eHealth and IOp sophistication increases across the continent, it’ll become increasingly important in providing accessible, relevant information to clinicians and other health professionals to help manage and improve their clinical and working practices and integrate healthcare across organisational boundaries.

  • IHE Pharmacy Technical Framework Supplements published

    Supplements to Interoperability (IOp) standards for pharmaceutical services have been released by Integrating the Healthcare Enterprise (IHE) Pharmacy Technical Committee. The  Pharmacy Technical Framework Supplements deal with four aspects:

    Pharmacy Dispense (DIS)Medication Treatment Plan (MTP)Pharmacy Pharmaceutical Advice (PADV)Pharmacy Prescription (PRE).

    There are three types of review. They started trial implementation on 21 October 2016. They’ll be tested at subsequent IHE Connectathons too. The third is by direct comments from individual users. Commenting online seems the most convenient way for Africa’s pharmacists and other healthcare professionals to contribute.

  • IOp’s not nearing its solution by much

    As eHealth expands and needs to transfer data from more parts to others, there’s no doubting the need for effective Interoperability (IOp). It seems there’s no doubt that it’s hard to achieve. A meeting of US hospital CIOs at the College of Healthcare Information Management Executives (CHIME), and reported by Fierce Healthcare, recognised that IOp’s a persistent challenge.  Observations and comments from the event offer salutary and realistic lessons for Africa’s eHealth. They included:

    Some progress has been made with help from the Office of the National Coordinator for Health IT (ONC), but there’s still a long way to go to be truly and semantically interoperableIOp’s not solved, and not even closeConsiderable effort and work’s still needed to ensure information is exchanged quickly and accurately between facilities“Behind the scenes, there’s a bunch of little mice on wheels that are taking the data from one system, manipulating it and sending it to another system. That’s a full-time job for a team, running these interfaces”One organisation exchanged about 500,000 records in a quarter, but failed to connect roughly 150,000, about 30%, because it couldn’t match patient’s IDs.

    These point to the realism that Africa’s health systems should adopt to their IOp plans and programmes. Two features of an effective approach are first, being clear and explicit about IOp’s benefits and how they’ll be delivered. Second, before starting, make sure that long-term sustainable finance and budgets are in place and reset the benefits to match affordability. These can help to avoid excessive IOp optimism.

  • South Africa’s moving on IOp polices and governance

    In its eHealth Strategy stretching from 2012 to this year, Dr Aaron Motsoaledi, South Africa’s Minister of Health, was clear. “Historically, health information systems in South Africa have been characterised by fragmentation and lack of coordination, prevalence of manual systems and lack of automation, and where automation existed, there was a lack of interoperability between different systems.” In a masterclass at this year’s eHealth ALIVE conference, Matthew Chetty from South Africa’s Council for Scientific and Industrial Research (CSIR) set out the Interoperability (IOp) policies and governance as part of the solution.

    Five levels are:

    Political context, with co-operating partners with compatible visions, aligned priorities and focused objectivesLegal IOp, needing aligned legislation so exchanged data’s accorded proper legal weightOrganisational IOp, needing co-ordinated processes so organisations achieve a previously agreed and mutually beneficial goalSemantic IOp alignment so precise meanings of exchanged information’s preserved and understood by all partiesTechnical IOp for interaction and transport so planning technical issues to link computer systems and services.

    Four sequential steps are needed to achieve these. They’re:

    Analyse the landscape and assess Health Information Systems (HIS) to define the IOp problemEstablish a set eHealth IOp standards, the National Health Normative Standards Framework for Interoperability in eHealth (HNSF)Establish a regime for IOp testing and certification, the National eHealth Interoperability LabEstablish the foundational ICT Infrastructure needed for IOp.

    Recommending eHealth standards for South Africa isn’t developing eHealth standards from scratch. It’s selecting the most appropriate set of standards from the range available from international standards organisations to support South Africa’s health system. The HNSF includes a process of reviewing eHealth base standards and selecting a stack that fits South Africa’s health systems requirements and health functions. Seven selection criteria are scalability, implementability, testable, cost, maturity, extendibility and flexibility. Six IOp components fit into a template of:

    Process for functional group and functionsTechnical, for Integrating the Healthcare Enterprise (IHE) profiles, general ICT standards, transfer and messaging standardsSemantic, for coding and terminology, content and structure and EHR standardsSecurity standards.

    Steady progress is underway. There’ll be much learning on route as standards are applied in eHealth investment decisions using the HNSF as a firm foundation

  • SNOMED and IHE were at eHealthALIVE

    Interoperability (IOp) was a core theme at eHealth ALIVE’s masterclasses. Charles Parisot of GE and Integrating the Healthcare Enterprise (IHE) set out the standards approach of IHE. IHE Is the most comprehensive set of open profile specifications. It’s based on widely adopted standards such as Health Level 7 (HL7), Digital Imaging and Communications in Medicine (DICOM), Internet Engineering Task Force (IETF) and the Organization for the Advancement of Structured Information Standards (OASIS). Standards in IHE’s technical frameworks extend across Health Information Exchange (HIE) transport, security, privacy, directories, workflow management, records sharing services, clinical data and data content

    It’s a resource with support for testing implementations in Connectathons organised on several continents, and has robust open source test tools, especially its Gazelle platform. There’s also a support services for users. 

    IHE profiles are already deployed by eHealth national programmes in many countries. They support health records sharing for hundreds of millions of patients in Canada, the European Union, Japan, Switzerland, USA and Uruguay. There are regional projects in China, Denmark, Germany, Italy and Slovenia.

    When IHE’s implemented in software applications, it can be tested for conformity through the internationally recognized, IHE Conformity Assessment of products based on ISO/IEC 17025 accredited laboratories. It’s ubiquity can ensure that IOp’s delivered by a large number of vendor products and open source implementations.

    Shelly Lipon from SNOMED outlined the services of Systematized Nomenclature of Medicine–Clinical Terms (SNOMED-CT). It’s the most comprehensive, multilingual, clinical healthcare terminology in the world, and comprises a resource with comprehensive, scientifically validated clinical content. This enables consistent, processable representations of clinical content in EHRs. Other international standards such as HL7, DICOM, IHE map onto it. This sophistication has resulted in more than fifty countries using it.

    When it’s implemented in software applications, it represents clinically relevant information consistently, reliably and comprehensively as an integral part of eHealth. SNOMED-CT’s features support the development of comprehensive high-quality clinical content in EHRs and standardises the representation of clinical phrases captured by clinicians. This enables their automatic interpretation. An important advantage is its clinically validated, semantically rich, controlled vocabulary facilitates that provide evolutionary growth to meet emerging requirements.

    These combine into benefits for individual patients and clinicians, and communities and whole populations. It also offers direct support for evidence-based healthcare, an essential component of eHealth benefits.

    Africa’s health systems are on the brink of needing IOp standards. IHE and SNOMED-CT should be part of their assessment.

  • What’s OSS’s role in Africa’s eHealth IOp?

    As Africa’s eHealth expands steadily, Open Source Software (OSS) can play a bigger role in advancing the Interoperability (IOp) requirements. Carl Fourie of Jembi Health Systems described these at eHealthALIVE 2016 in Johannesburg.

    He distinguished integration from IOp. Integration means there’s custom code to connect two or more systems together. IOp means that two or more systems work together unchanged even though they weren't designed to work together. Integrating two systems already interoperable is trivial. They just need configuring to know about each other. Integrating systems that aren’t interoperable  is more complicate so that IOp and standards, or at least specifications, open or otherwise, are needed.

    OSS isn’t limited to code or software. It’s designed to be collaborative and reduce entry and engagement barriers. There’s numerous licenses, such as BSD, Mozilla, GPL and OpenHIE. OSS isn’t:

    At no cost because freely available doesn’t mean freeInferior in designNot mutually exclusiveCan include commercial support.

    OpenHIE is a global, mission-driven community of practice for Health Information Exchange (HIE). It’s dedicated to improve the health of the underserved through open and collaborative, development and support for country driven, large-scale health information sharing architectures. It achieves this by:

    Enabling large scale health information IOpOffering freely available standards-based approaches and reference technologiesSupporting users’ needs through peer technical assistance communities.

    Its architecture and workflows based on IHE standards, with illustrative tools and reference technologies for its architectural components. User communities support its architecture advancement, workflows, reference technologies and implementing IOp HIE in low Resource settings. It fits much of Africa’s eHealth.

    Services are provided at points of care in a care programme, such as communicable diseases. Information about these person-centric care services may be saved to one or several databases. There may be other programmes, such as Non-communicable Diseases (NCDs), also with several points of care that write person-centric information to numerous databases. As databases proliferate, information pertaining to each individual needs capturing to confirm that episodes are all chapters in each patient’s health story.

    In this setting, OpenHIE connects the data silos using its architecture and a set of reference tools that can be deployed as centrally hosted or a cloud-based health information sharing service in a country or project. It can provide access to data about each patient’s care over time and across different care sites. Underpinning this is communications between healthcare professionals as members of a healthcare teams. The architecture has three layers:

    Open component, comprising  terminology service, client registry, shared health record, Health Management Information System (HMIS), facility registry and health worker registryIOp service, comprising authentication, inter-linked registry, entity matching, mediators, adaptorsExternal systems, extend across mobile, clinic, lab, hospital and HMIS.

    The IOp layer’s a central exchange, or service bus. It provides:

    Easy message routing between componentsSecurity, authentication and authorisationTransaction logging by viewing messages as they move through the exchangeAuditing by logging standards for compliance with international requirementsTransforming messages from one format to anotherValidating message contentsOrchestrating workflow.

    Core workflows supported by a complete OpenHIE implementation include:

    Save a new demographic recordsQuery for a demographic recordsQuery by IDQuery by fuzzy matchesUpdate existing demographic recordsUpdate inter-linked recordsQuery for inter-linked records, such as providers, facilities, organisations and servicesSave client encounter documentsQuery for client encounter documentsSave aggregate health data to HMIS.

    OpenHIE’s communities are built around each of the framework components. Their roles and responsibilities include:

    Develop and refine OpenHIE mission, vision, values and collaborative leadershipCultivate domain-specific communities of practiceDefine interoperability specifications and workflowsMaintain forum for technology developers and implementersIdentify and refine appropriate interoperability standards, working within Integrating the Healthcare Enterprise (IHE) processDevelop implementation guidance through the OpenHIE Implementers NetworkDevelop and support reference technologies.Test technologies against standards to ensure compliance.

    The OpenHIE community is a route into participation. Ways in include:

    Community Google GroupDirect enquiresOpenHIE Sub-communitiesOpenHIE Mailing Lists, an invaluable blogWebsitesWiki.

    OpenHIE has a continuing role in Africa’s eHealth. Learning more’s the right place to start.

  • South Africa’s IOp’s moving on

    As Interoperability (IOp) becomes more important for South Africa’s eHealth strategy, Mbulelo Cabuk, Director of South Africa’s National Health Information System at the National Department of Health (NDoH) describes what happens next in the country’s eHealth programme. At eHealthALIVE2016 in Johannesburg, he said he sees IOp in healthcare not only to the extent to which systems and devices can exchange data, but as interpreting the data and displaying it in a user-friendly way for users. This range of goals is vital for users to realise eHealth’s value.

    Three IOp levels are:

    Foundational interoperability for data, such as clinical image files exchanged from one ICT system to anotherStructural interoperability for exchanging data from one system so the next can be interpreted at the data field level and preserved or unaltered, ideally creating a uniform movement of healthcare data remaining unchanged in its operational and clinical formsSemantic interoperability to make codified data clear because systems use the same vocabulary with no discrepancies between EMRs.

    Standards that support these IOp requirements provide a common IOp framework. Numerous types of standards are needed, including data exchange, semantic, security, safety, privacy, pharmacy and architecture. These are set out in the National Health Normative Standards Framework for Interoperability in eHealth in South Africa (HNSF).

    South Africa already has several eHealth programmes. District Health Information System (DHIS), is used for most routine healthcare information in eight of the nine Provincial DoHs. Western Cape DoH uses Sinjani. These are primary sources for most routine data and indicators for Monitoring and Evaluation (M&E). Both DHIS and Sinjani have expanded over the years to include many extra modules, such as data for hospitals, school health, ward-based outreach teams, emergency medical care data, environmental health data, national core standards, and client satisfaction surveys.

    Patient-based surveillance systems implemented nationally include ETR.Net for TB and the Tier.Net for the lifelong management of HIV clients. eHealth in provinces include:

    Building from the current position needs nine challenges addressing. These are common to many countries, and are:

    Clinicians expected to maintain too many registersPatient files managed in many places, with inconsistent numbering schemes in clinics, leading to duplicate records and filesThese two result in poor case managementManual calculations generate inaccuracies, such as adding data from tick registers used by clinicians to produce a monthly summary sheetsHeavy maintenance, with many import-export processes at district and provincial levelsMany disparate patient repositories, such as Tier.net, MomConnect and Health Patient Registration System (HPRS)Many disparate data repositories in districts and provincesGaps between data collection and usePoor data quality, usually improved where data’s used.

    A transition from routine surveillance Information systems to patient and case-based Information systems is the planned solution. It will also deal with the complications of four health system tiers of national, provincial, district and facility that need addressing. It has four parts:

    Efficient manual systemsDigitising selected dataAutomated operations by implementing patient-based information systemsShared EHRs.

    Progress towards electronic patient-based information systems includes seven initiatives:

    HNSF and standards-based exchangeHNSF pilots and reference implementation to exchange identifier and demographic patient data with Tier.net completed successfullyImproved HPRSHealth Provider Registration SystemPublic health facility unique identifiersAssessment of Primary Health Care Systems (PHCS) and Hospital Information Systems (HIS)Development and rollout of National Health Information Repository and Datawarehouse (NHIRD).

    HPRS is a vital component of these initiatives. It includes:

    Barcode scanning of ID books and drivers’ licences and biometric dataPatient look-up facilitiesGenerating patient file numbersMaintaining patient detailsLinking patients to Primary Healthcare (PHC) facilitiesVisit records, including dates, times and purposesManagement information.

    These are supported by a range of actions. For patient-based information:

    Integration and IOp as the key to derive value for patients and providers and patients and successful implementationComplete integrating Tier.net and ETR.net already underway, for better case management and linking patients in care and retention of patient on careAdapting district health management information systems policiesStreamlining workflow at health facilities using information systems and developing the information management roles of district, provincial and national officesIntegrating patient administration and clinical systems where there is stable patient administrationShifting culture to improve filing systems, patient admin system, clinical record keeping – training clinical providers and administrative, data capture staff

    For surveillance systems and data use, initiatives are:

    Enhancing monitoring of data submission rates to timeliness and completeness, and building on timeliness improvements already achievedStrengthening feedback between workers who generate information and management at all levels of the health systemMaking information widely accessibleAddressing the demand and supply continuum.

    These combine into a considerable and demanding programme. The new Ministerial Advisory Committee on eHealth, a think tank, will help to steer the course. A remaining challenge’s the ubiquitous African challenge of providing the budgets to support the considerable and sustained finance for the eHealth programme. It’s a vital step in what’s next.

  • Achieving IOp needs clear principles and structure

    Why’s Interoperability (IOp) so challenging? Charles Parisot of GE and Integrating the Healthcare Enterprise (IHE) at eHealthALIVE 2016 set out a constructive approach in a masterclass. A first step’s recognising what often goes wrong with Interoperability (IOp) initiatives. Specifying the technical details of information flows between different ehealth systems is very technical, complex. Consequently, standards are difficult to select and enforce. It’s seen as a technical problem, not important for policy setting. Systems and applications vendors figure it out when they deploy their ICT teams.

    These are two inappropriate positions. IOp difficulties can be simplified, and IOp and standards are policy matters. If these are not in place, health system’s ICT teams carry the can for failure. eHealth programmes have to control IOp because:

    Vendor choice, so enabling procurement of ICT systems from different vendors or open source, both initially and over time, so needing future proofingConsistent security and privacy policies are simpler when relying on same technical measuresQuality in exchange and information reduces finger pointing between healthcare providers and health policy makers and systems buyers and vendors.

    The IOp challenge then becomes a reality of dealing with:

    Clinical worlds need information from different sources and formats to be used together to provide an accurate picture of patients’ healthcareClinical practices keep changing and developingHealthcare needs analyses of patient data at population levelsDifferent terminologies and classifications have developed over time to meet specific use cases and deliver different functionalityLocal, national and international reporting requirements keep evolving.

    eHealth’s defined semantic IOp as a priority, and most national eHealth strategies address it as an important initiative. Global eHealth initiatives have also stressed the need for two or more eHealth systems to use and exchange both computer interpretable data and human understandable data and knowledge. While everyone prioritises it, it still seems hard to do. Even more demanding is that semantic IOp’s only a part of IOp’s whole scope. Other dimensions include:

    Legal and regulatoryPolicyHealthcare processesInformation structures and codingApplicationsICT infrastructureUnderpinning standards, profiles, certification, security, privacy and governanceStrategic, tactical and operational requirements.

    A practical approach’s to acknowledge the current standards that exist from international standard organisations, and their potential value. From this, it can be feasible to draw a line in the sand and mandate profiles and standards. It should be based on an understanding and ownership of them, leading to sustainability. The scale is huge, so starting small with contained use cases to demonstrate the value and build an IOp culture is a dependable strategy.

    Taking control of IOp needs a recognition that details of information flows between different ehealth systems is very complex. It’s manageable if it’s focus is on a use case providing a description of an IOp problem. It should also be realistic about the difficulties of choosing standards, when to use available profiles and when to develop local standards using services such as Systematized Nomenclature of Medicine (SNOMED) value sets.

    A national IOp centre has two essential roles. It can turn policy priorities as use cases into profiles and standards-based IOp specifications. Second, it can offer test tools and organise conformity assessments. Both ensure IOp consistency across health systems.

  • IHE’s important for Africa’s eHealth

    As Africa’s eHealth moves towards greater Interoperability (IOp), it’s important that health system and eHealth leaders understand the value of Integrating the Healthcare Enterprise (IHE). It has an invaluable role to play in driving IOp ahead as part of the South African Normative Standards Framework for Interoperability in eHealth. It was timely for so Lapo Bertini of IHE International Board, IHE Europe and Deputy Co-Chair of Dedalus to present the Anatomy of an IHE Integration Profile XDS-MS to this year’s eHealth ALIVE conference. He dealt with:What’s an IHE Integration Profile?What’s it for?What are the advantages of adopting IHE Integration Profiles?

    The overarching model’s a combination of content, transport and security. XDS’s a transport integration profile. It doesn’t define content. Like PC filesystems, it doesn’t define file types such as PDF, Word, Text or JPEG files that are just collections of bytes. The file type’s what links              files to an application. XDS Content Profiles define what the bytes mean.

    Content Profiles define document formats and XDS extensions for specific applications. These include:

    XDS-MS, Medical SummariesBasic Patient Privacy Consents (BPCC)Exchange of Personal Health Record Content (XPHR)Emergency Department Referral (XDR)Scanned Documents (XDS–SD)Lab Reports (XDA-Lab).

    XDS-MS builds on and constrains HL7 CDA and the Care Record  Summary (CRS)  implementation guide. It also defines the required and optional sections for the Acute Care Discharge and Specialist Referral use cases. In addition, it constrains the most important                 sections of medical summaries, medication, allergies and problems.

    Its three levels are:

    Header, which’s always structured and codedTitle-coded sections with non-structured nor coded content of text, lists and tables, and  an XML Style Sheet for simple viewingMedical problems and allergies as highly structured text that’s easy to import and pars, where medical problems and allergies have a fine-grain structure with optional coding and the coding scheme identified explicitly.

    These documents combine in Document Exchange Integration Profiles comprising:

    Document Sharing XDSMedia Interchange XDMReliable Pt-Pt Interchange XD.

    IHE content profiles are a layer on top of XDS where:

    Content Profiles, where document use cases and translation of document content comprises registry metadata and published separatelyFord document source and document consumer actors, a creator and consumer of contentBase standards for content profiles, including Health Level 7, Clinical Document Architecture   (HL7-CDA) and Dicom.

    There’s also a set of testing tools:

    Validation services used by the Gazelle for IHE Clinical Documentation Architecture (IHE CDA), and other standards such as PHARM; BASIC; XD* for  XDS.b, XCA, XDM;  XDW, HL7 Certificates, Digital Imaging and Communications in Medicine (Dicom). A Gazelle website provides more information and another provides information about CDA documents Other    examples are the USA’s Office of the National Co-ordinator (ONC) at the Department of Health and Human Services which has links to a CDA validator website)IHE has its own testing tools.

    As Africa’s health systems expand their eHealth services, IHE will become more important. Future eHealthALIVE and Acfee events will return to this theme many times for the benefit of Africa’s health and eHealth leaders.

  • What’s an IHE Connectathon?

    At eHealthALIVE 2016 in Johannesburg, the interoperability (IOp) emphasised the role and value of the connectathons run by the Integrated Health Enterprise (IHE). It sounds a bit exhausting, so what is it?

    IHE Connectathons are controlled, supervised and neutral environments. They’re where vendors meet to test the IOp rigour of their products with other vendors. The objective’s to test the conformity to IHE Profiles of participating systems. It evaluates, and if successful, validates IOp between systems, following clinical workflows.

    IHE Profiles are important to enable seamless and secure exchanges of health information, including healthcare providers and patients. Exchanges can be local, regional, national or global

    Connectahons are held in several locations, with the US and Europe hosting active initiatives. It’s important that eHealth teams in Africa’s health ministries and eHealth projects keep up to date on Connectahtons’ results and progress.