The document discusses uploading personal health device data to a FHIR server. It describes:
1) Mapping device data models like 11073 to FHIR resources like Observation, DeviceComponent, and Patient to represent the information in a standardized way.
2) Methods for the personal health gateway to securely upload the device data using FHIR over HTTPS with OAuth authorization and ensuring no loss of information.
3) Considerations for managing patient identity and properly associating observations with the correct patient resource on the server.
The document discusses governance processes for the creation and curation of FHIR profiles and other artifacts. It provides examples of processes used by HL7 International, various HL7 affiliate organizations like France and Germany, and projects like Argonaut in the US. It emphasizes the importance of governance, stakeholder involvement, testing, and maturity models to advance artifacts from draft to normative status. The best practices highlighted include using issue tracking, connectathons for testing, and ensuring representation of all stakeholders in governance and review.
This document summarizes an presentation on the advanced .NET API for FHIR by Ewout Kramer of Furore Health Informatics. The presentation introduces the ElementModel, which provides low-level access to FHIR instance data without using POCO classes. It also covers terminology services, FhirPath support, and other features of the .NET API like resource identities and extension manipulation.
This document summarizes a presentation about FHIR (Fast Healthcare Interoperability Resources). It defines FHIR as the latest HL7 standard for exchanging electronic healthcare information using standardized "resources" as basic building blocks. The presentation describes what resources are and provides examples, explains the FHIR acronym, and outlines four paradigms for interoperability supported by FHIR including REST, documents, messages, and services. It also provides links to FHIR specification documentation and outlines the FHIR timeline.
The document discusses the HL7 FHIR Foundation, which promotes global adoption and implementation of the FHIR standard. The Foundation provides educational materials, tools, websites and project support to help the FHIR community collaborate and expand interoperability. It also discusses the FHIR community, which publishes implementation guides to support FHIR. Some guides are published by HL7, while others are published directly by the community. The Foundation provides ongoing infrastructure services to support the FHIR community.
Grahame Grieve presented on what's new in FHIR R4. Key points include:
- Parts of R4 will become normative standards while others remain trial use.
- FHIR certification programs are being introduced to test knowledge and skills.
- Inter-version support, bulk data extraction, and GraphQL query support are areas of expansion.
- There will be some breaking changes following community consultation.
- New content is being added around public health, devices, and insurance plans.
- The definition process and logical models are being strengthened.
- The FHIR Foundation is taking on additional responsibilities to support implementation.
Dev days 2017 advanced directories (brian postlethwaite)DevDays
FHIR provides several core resources for representing directories, including Organization, Location, Practitioner, HealthcareService, and PractitionerRole. In STU3, additional resources like Schedule, Referral, and CarePlan help support common directory use cases. For R4, a new HL7 Validated Healthcare Services Directory implementation guide is being developed to further standardize directories using FHIR, with potential new resources like OrganizationAssociation. Directories in FHIR allow flexible hierarchies and relationships between providers, locations, and services.
- FHIR provides a standard way to represent clinical documents as bundles of FHIR resources bound together with a Composition resource similar to a CDA header and narrative.
- Document bundles can be generated from or decomposed into their component resources using FHIR APIs and operations.
- Validating, storing, and exchanging clinical documents as FHIR resources satisfies the same persistence, stewardship, and authentication requirements as CDA documents.
- C-CDA on FHIR is an HL7 implementation guide that defines FHIR profiles for representing C-CDA templates using FHIR resources and profiles. It maps each C-CDA document template to a FHIR Composition profile along with contained sections. Coded data is represented using relevant US Core profiles.
- The guide includes Composition profiles, examples, and extensions to represent key parts of C-CDAs in FHIR. Common document types like CCD are profiled.
- Profiles leverage relevant US Core profiles for resources referenced in C-CDA documents, like Patient, Practitioner, AllergyIntolerance, and Condition.
The document discusses governance processes for the creation and curation of FHIR profiles and other artifacts. It provides examples of processes used by HL7 International, various HL7 affiliate organizations like France and Germany, and projects like Argonaut in the US. It emphasizes the importance of governance, stakeholder involvement, testing, and maturity models to advance artifacts from draft to normative status. The best practices highlighted include using issue tracking, connectathons for testing, and ensuring representation of all stakeholders in governance and review.
This document summarizes an presentation on the advanced .NET API for FHIR by Ewout Kramer of Furore Health Informatics. The presentation introduces the ElementModel, which provides low-level access to FHIR instance data without using POCO classes. It also covers terminology services, FhirPath support, and other features of the .NET API like resource identities and extension manipulation.
This document summarizes a presentation about FHIR (Fast Healthcare Interoperability Resources). It defines FHIR as the latest HL7 standard for exchanging electronic healthcare information using standardized "resources" as basic building blocks. The presentation describes what resources are and provides examples, explains the FHIR acronym, and outlines four paradigms for interoperability supported by FHIR including REST, documents, messages, and services. It also provides links to FHIR specification documentation and outlines the FHIR timeline.
The document discusses the HL7 FHIR Foundation, which promotes global adoption and implementation of the FHIR standard. The Foundation provides educational materials, tools, websites and project support to help the FHIR community collaborate and expand interoperability. It also discusses the FHIR community, which publishes implementation guides to support FHIR. Some guides are published by HL7, while others are published directly by the community. The Foundation provides ongoing infrastructure services to support the FHIR community.
Grahame Grieve presented on what's new in FHIR R4. Key points include:
- Parts of R4 will become normative standards while others remain trial use.
- FHIR certification programs are being introduced to test knowledge and skills.
- Inter-version support, bulk data extraction, and GraphQL query support are areas of expansion.
- There will be some breaking changes following community consultation.
- New content is being added around public health, devices, and insurance plans.
- The definition process and logical models are being strengthened.
- The FHIR Foundation is taking on additional responsibilities to support implementation.
Dev days 2017 advanced directories (brian postlethwaite)DevDays
FHIR provides several core resources for representing directories, including Organization, Location, Practitioner, HealthcareService, and PractitionerRole. In STU3, additional resources like Schedule, Referral, and CarePlan help support common directory use cases. For R4, a new HL7 Validated Healthcare Services Directory implementation guide is being developed to further standardize directories using FHIR, with potential new resources like OrganizationAssociation. Directories in FHIR allow flexible hierarchies and relationships between providers, locations, and services.
- FHIR provides a standard way to represent clinical documents as bundles of FHIR resources bound together with a Composition resource similar to a CDA header and narrative.
- Document bundles can be generated from or decomposed into their component resources using FHIR APIs and operations.
- Validating, storing, and exchanging clinical documents as FHIR resources satisfies the same persistence, stewardship, and authentication requirements as CDA documents.
- C-CDA on FHIR is an HL7 implementation guide that defines FHIR profiles for representing C-CDA templates using FHIR resources and profiles. It maps each C-CDA document template to a FHIR Composition profile along with contained sections. Coded data is represented using relevant US Core profiles.
- The guide includes Composition profiles, examples, and extensions to represent key parts of C-CDAs in FHIR. Common document types like CCD are profiled.
- Profiles leverage relevant US Core profiles for resources referenced in C-CDA documents, like Patient, Practitioner, AllergyIntolerance, and Condition.
Richard Ettema presented on test driven development using FHIR. He discussed how continuous testing through TestScripts can help ensure interoperability and reduce risks compared to one-time testing. Touchstone is a publicly available testing platform that executes TestScripts against FHIR implementations. Organizations can use Touchstone for conformance testing, during software development, and to author their own TestScripts. Hands-on exercises demonstrated registering with Touchstone and executing sample TestScripts.
Integrating with the epic platform fhir dev days 17DevDays
Zach Vaughan presented on integrating with the Epic platform using FHIR and emerging standards. Epic supports FHIR through its open APIs and the FHIRcast event notification system, allowing external applications and systems to access data in the Epic EHR and be notified of relevant events. FHIR resources like Patient, Practitioner, and Observation are available today from Epic, with more like Medication Request and Diagnostic Report coming in 2018.
An implementation guide (IG) defines how FHIR resources should be used to solve a particular problem. It includes use cases, actors, examples, and other documentation. IGs can have different scopes, from a single use case to a national strategy. The content of an IG depends on its scope, audience, and producing organization. Technical sections describe interactions and profiles, while other sections cover terminology, security, and conformance resources. Tools can help author and publish IGs.
FHIR provides standards for security including authentication, authorization, access control, digital signatures, audit trails, and security labels. Authentication verifies a user's identity, while authorization determines what resources a user can access. Access control engines enforce authorization and other rules. Digital signatures can be applied to resources and bundles to ensure integrity. Audit trails and provenance track access. Security labels make access restrictions like confidentiality explicit. Ongoing work continues on authorization models and how to apply signatures to RESTful resources.
Building bridges devdays 2017- powerpoint templateDevDays
This document discusses mapping data from HL7 Version 2 (V2) format to FHIR resources using RESTful transactions. It describes how an integration engine can:
1) Use conditional updates and patient identifiers to determine whether to create or update FHIR patient resources from V2 data.
2) Use conditional deletes with tags to purge and recreate FHIR allergy intolerance resources from updated V2 data.
3) Address challenges around referencing resources before they have URLs and handling merges or updates that modify existing data.
The document discusses the FHIR Workflow project which aims to improve how FHIR represents clinical workflows and requests. It describes the process undertaken over two years, including defining new workflow patterns using Request, Definition, and Event resources. It provides examples of how these patterns can be used to represent different workflow scenarios and statuses. Future plans include aligning all FHIR resources with these patterns and publishing more workflow examples.
The Structured Data Capture (SDC) project aimed to standardize how healthcare data elements and questionnaires are shared using FHIR. The SDC implementation guide supports pre-populating and auto-populating questionnaire responses using mappings between questions and data elements. This allows reducing data entry errors and time. Future work will generalize the SDC guide for international use and explore additional ways to map questions to source data.
Dev days 2017 referrals (brian postlethwaite)DevDays
- A referral involves directing a patient to a medical specialist by a primary care physician. It can involve simply filling out paperwork or sharing detailed care information.
- Creating a referral in FHIR involves including basic patient and sender details, referral service details, and optional supporting information as attachments or references.
- Tracking referrals requires understanding one's role in the workflow as sender, receiver, processor or delivery mechanism, and using resources like ReferralRequest, Task, and directories.
This document describes FHIR tools that allow users to connect to FHIR servers, browse and manage FHIR resources like code systems, value sets, questionnaires and capability statements. It also provides a link to browse the FHIR registry for more information on FHIR tooling ecosystems.
Dev days 2017 questionnaires (brian postlethwaite)DevDays
FHIR questionnaires can be used to define structured data capture forms and surveys. Questionnaires are defined using the Questionnaire resource and submitted data is contained in the QuestionnaireResponse resource. Questionnaires support validation rules, pre-population of data, mapping responses to other FHIR resources, and more advanced features like scoring. Questionnaires provide a standards-based way to define and capture structured data in healthcare and other domains.
The document discusses IHE profiles that use FHIR and DICOMweb standards to address interoperability use cases. IHE develops integration profiles that define actors, transactions, and options to enable seamless health information exchange. Several IHE domains are working with FHIR and DICOMweb, including Radiology, IT Infrastructure, and Patient Care Coordination. Numerous profiles are described that specify how FHIR resources and DICOMweb transactions support workflows like image sharing, alert communication, clinical mapping, and care planning. IHE brings together healthcare stakeholders to test and promote standardized implementation of profiles through connectathons.
This document discusses validation of FHIR resources in .NET and Java. It provides an overview of validation inputs and approaches in the two languages. In .NET, validation uses packages that handle instance data, specifications, terminology services, and validation. The Java HAPI library similarly provides a parser error handler for structural validation and a validator for semantic validation based on profiles and rules. The document demonstrates using validators in code and discusses considerations for validation approaches.
This document summarizes a presentation on advanced test driven development with FHIR. It introduces complex testing concepts like FHIRPath expressions for assertions, rules and rulesets, and client/peer-to-peer testing. It also discusses the Touchstone test platform's conformance analytics dashboards and APIs for integrating testing into continuous integration pipelines. The presentation concludes with an overview of hands-on exercises to apply these advanced testing techniques.
Furore devdays 2017- profiling academy - profiling guidelines v1DevDays
The document summarizes guidelines for creating FHIR profiles and extensions. It discusses planning profiling work, collaborating with others, and delivering profiles and extensions. Key points include reusing existing profiles and value sets, using naming conventions, filling narrative and definition fields, constraining data types, considering future uses of data, and making extensions and value sets reusable. The document promotes best practices for functional mapping, issue tracking, implementation guides, descriptions, and more.
- HL7 is a standard for exchanging health-related information between medical applications. It defines formats for transmitting patient records, lab results, and billing information.
- FHIR (Fast Healthcare Interoperability Resources) is the latest HL7 standard, combining features of previous versions while using modern web technologies like RESTful APIs and JSON/XML. It defines "resources" that can be accessed via HTTP.
- HAPI FHIR is a popular open-source Java library that implements the FHIR standard. It provides classes for all FHIR resources and supports parsing, validation, storage, and client/server capabilities.
Fhir dev days_basic_fhir_terminology_servicesDevDays
The document provides an overview of basic FHIR terminology services including:
- CodeSystem resources which define collections of terms and can be used for lookups and subsumption checks.
- ValueSet resources which define sets of codes drawn from CodeSystems and can be expanded or used to validate codes.
- ConceptMap resources which define mappings between ValueSets and can be used for translation.
- Common terminology operations like $expand, $lookup, $validate-code and $translate.
- Examples of integrating terminology in applications and some tips for using terminology services efficiently.
Fhir dev days 2017 fhir profiling - overview and introduction v07DevDays
This document provides an overview of FHIR profiling and introduces some key concepts:
1. Profiling is needed to adapt FHIR resources to specific contexts and local requirements. Profiles constrain elements and extensions to describe how FHIR is used.
2. Conformance resources like StructureDefinition, OperationDefinition, and CapabilityStatement define profiles, operations, and server capabilities. Profiles are published to repositories and drive validation, code generation, and more.
3. Extensions allow custom elements to be introduced where needed. Extensions and how they can be used in profiles and resources are described.
4. Implementation guides combine related artifacts like profiles and page content into conformance packages for sharing implementations.
Mirjam Baltus introduced the Hl7.Fhir.STU3 .NET package for working with FHIR resources and APIs. It includes classes mapped from the FHIR specification to represent resources and data types in C#, as well as a FhirClient for interacting with FHIR servers through CRUD and search operations. Extensions can be added to resources, and the client supports transactions, paging through search results, and inspecting request/response details. Hands-on coding sessions were encouraged to explore using the API.
This document provides an overview of a two-day training on building clinical scenarios using FHIR (Fast Healthcare Interoperability Resources). Day one focuses on reviewing key FHIR elements like resources and references, and using tools like clinFHIR to create logical models, resource models, and reference graphs. Day two will cover structured and coded data as well as generating FHIR artifacts like extensions, value sets, and profiles. Exercises are provided to help attendees work through creating a sample clinical document.
Fhir dev days_advanced_fhir_terminology_servicesDevDays
This document discusses advanced terminology services for FHIR including SNOMED CT. It provides an overview of FHIR terminology including concept maps, code systems, and value sets. It demonstrates Shrimp for browsing terminologies, Snapper for authoring FHIR resources, and discusses implicit value sets, versioning, the Expression Constraint Language, and code system operations like $subsumes and $closure. Practical tips are provided for efficient terminology server usage and handling complex value sets.
The document discusses the challenges of implementing electronic health records (EHR) in Slovenia and the benefits of using an openEHR approach. It describes how Slovenia created a Smart Healthcare & Wellbeing Cluster to deliver value through an open data platform based on openEHR standards. This has resulted in a vendor-neutral clinical data repository being used at a children's hospital in Slovenia and as part of the national health interoperability backbone. The openEHR approach is now also being used for EHR systems in Moscow, Russia.
NordForsk Open Access Reykjavik 14-15/8-2014: H2020NordForsk
This document summarizes the European Commission's policies on open access to research data and publications in Horizon 2020. Key points include:
1) Horizon 2020 will require open access to publications and encourage open access to research data through a pilot program. Projects will need to submit a data management plan and may need to deposit data in a repository.
2) The goals are to optimize the impact of publicly-funded research, enable better science, and promote economic growth and broader access.
3) Support for open access includes funding for e-infrastructure projects, training, helpdesks and guidelines on open data management.
Richard Ettema presented on test driven development using FHIR. He discussed how continuous testing through TestScripts can help ensure interoperability and reduce risks compared to one-time testing. Touchstone is a publicly available testing platform that executes TestScripts against FHIR implementations. Organizations can use Touchstone for conformance testing, during software development, and to author their own TestScripts. Hands-on exercises demonstrated registering with Touchstone and executing sample TestScripts.
Integrating with the epic platform fhir dev days 17DevDays
Zach Vaughan presented on integrating with the Epic platform using FHIR and emerging standards. Epic supports FHIR through its open APIs and the FHIRcast event notification system, allowing external applications and systems to access data in the Epic EHR and be notified of relevant events. FHIR resources like Patient, Practitioner, and Observation are available today from Epic, with more like Medication Request and Diagnostic Report coming in 2018.
An implementation guide (IG) defines how FHIR resources should be used to solve a particular problem. It includes use cases, actors, examples, and other documentation. IGs can have different scopes, from a single use case to a national strategy. The content of an IG depends on its scope, audience, and producing organization. Technical sections describe interactions and profiles, while other sections cover terminology, security, and conformance resources. Tools can help author and publish IGs.
FHIR provides standards for security including authentication, authorization, access control, digital signatures, audit trails, and security labels. Authentication verifies a user's identity, while authorization determines what resources a user can access. Access control engines enforce authorization and other rules. Digital signatures can be applied to resources and bundles to ensure integrity. Audit trails and provenance track access. Security labels make access restrictions like confidentiality explicit. Ongoing work continues on authorization models and how to apply signatures to RESTful resources.
Building bridges devdays 2017- powerpoint templateDevDays
This document discusses mapping data from HL7 Version 2 (V2) format to FHIR resources using RESTful transactions. It describes how an integration engine can:
1) Use conditional updates and patient identifiers to determine whether to create or update FHIR patient resources from V2 data.
2) Use conditional deletes with tags to purge and recreate FHIR allergy intolerance resources from updated V2 data.
3) Address challenges around referencing resources before they have URLs and handling merges or updates that modify existing data.
The document discusses the FHIR Workflow project which aims to improve how FHIR represents clinical workflows and requests. It describes the process undertaken over two years, including defining new workflow patterns using Request, Definition, and Event resources. It provides examples of how these patterns can be used to represent different workflow scenarios and statuses. Future plans include aligning all FHIR resources with these patterns and publishing more workflow examples.
The Structured Data Capture (SDC) project aimed to standardize how healthcare data elements and questionnaires are shared using FHIR. The SDC implementation guide supports pre-populating and auto-populating questionnaire responses using mappings between questions and data elements. This allows reducing data entry errors and time. Future work will generalize the SDC guide for international use and explore additional ways to map questions to source data.
Dev days 2017 referrals (brian postlethwaite)DevDays
- A referral involves directing a patient to a medical specialist by a primary care physician. It can involve simply filling out paperwork or sharing detailed care information.
- Creating a referral in FHIR involves including basic patient and sender details, referral service details, and optional supporting information as attachments or references.
- Tracking referrals requires understanding one's role in the workflow as sender, receiver, processor or delivery mechanism, and using resources like ReferralRequest, Task, and directories.
This document describes FHIR tools that allow users to connect to FHIR servers, browse and manage FHIR resources like code systems, value sets, questionnaires and capability statements. It also provides a link to browse the FHIR registry for more information on FHIR tooling ecosystems.
Dev days 2017 questionnaires (brian postlethwaite)DevDays
FHIR questionnaires can be used to define structured data capture forms and surveys. Questionnaires are defined using the Questionnaire resource and submitted data is contained in the QuestionnaireResponse resource. Questionnaires support validation rules, pre-population of data, mapping responses to other FHIR resources, and more advanced features like scoring. Questionnaires provide a standards-based way to define and capture structured data in healthcare and other domains.
The document discusses IHE profiles that use FHIR and DICOMweb standards to address interoperability use cases. IHE develops integration profiles that define actors, transactions, and options to enable seamless health information exchange. Several IHE domains are working with FHIR and DICOMweb, including Radiology, IT Infrastructure, and Patient Care Coordination. Numerous profiles are described that specify how FHIR resources and DICOMweb transactions support workflows like image sharing, alert communication, clinical mapping, and care planning. IHE brings together healthcare stakeholders to test and promote standardized implementation of profiles through connectathons.
This document discusses validation of FHIR resources in .NET and Java. It provides an overview of validation inputs and approaches in the two languages. In .NET, validation uses packages that handle instance data, specifications, terminology services, and validation. The Java HAPI library similarly provides a parser error handler for structural validation and a validator for semantic validation based on profiles and rules. The document demonstrates using validators in code and discusses considerations for validation approaches.
This document summarizes a presentation on advanced test driven development with FHIR. It introduces complex testing concepts like FHIRPath expressions for assertions, rules and rulesets, and client/peer-to-peer testing. It also discusses the Touchstone test platform's conformance analytics dashboards and APIs for integrating testing into continuous integration pipelines. The presentation concludes with an overview of hands-on exercises to apply these advanced testing techniques.
Furore devdays 2017- profiling academy - profiling guidelines v1DevDays
The document summarizes guidelines for creating FHIR profiles and extensions. It discusses planning profiling work, collaborating with others, and delivering profiles and extensions. Key points include reusing existing profiles and value sets, using naming conventions, filling narrative and definition fields, constraining data types, considering future uses of data, and making extensions and value sets reusable. The document promotes best practices for functional mapping, issue tracking, implementation guides, descriptions, and more.
- HL7 is a standard for exchanging health-related information between medical applications. It defines formats for transmitting patient records, lab results, and billing information.
- FHIR (Fast Healthcare Interoperability Resources) is the latest HL7 standard, combining features of previous versions while using modern web technologies like RESTful APIs and JSON/XML. It defines "resources" that can be accessed via HTTP.
- HAPI FHIR is a popular open-source Java library that implements the FHIR standard. It provides classes for all FHIR resources and supports parsing, validation, storage, and client/server capabilities.
Fhir dev days_basic_fhir_terminology_servicesDevDays
The document provides an overview of basic FHIR terminology services including:
- CodeSystem resources which define collections of terms and can be used for lookups and subsumption checks.
- ValueSet resources which define sets of codes drawn from CodeSystems and can be expanded or used to validate codes.
- ConceptMap resources which define mappings between ValueSets and can be used for translation.
- Common terminology operations like $expand, $lookup, $validate-code and $translate.
- Examples of integrating terminology in applications and some tips for using terminology services efficiently.
Fhir dev days 2017 fhir profiling - overview and introduction v07DevDays
This document provides an overview of FHIR profiling and introduces some key concepts:
1. Profiling is needed to adapt FHIR resources to specific contexts and local requirements. Profiles constrain elements and extensions to describe how FHIR is used.
2. Conformance resources like StructureDefinition, OperationDefinition, and CapabilityStatement define profiles, operations, and server capabilities. Profiles are published to repositories and drive validation, code generation, and more.
3. Extensions allow custom elements to be introduced where needed. Extensions and how they can be used in profiles and resources are described.
4. Implementation guides combine related artifacts like profiles and page content into conformance packages for sharing implementations.
Mirjam Baltus introduced the Hl7.Fhir.STU3 .NET package for working with FHIR resources and APIs. It includes classes mapped from the FHIR specification to represent resources and data types in C#, as well as a FhirClient for interacting with FHIR servers through CRUD and search operations. Extensions can be added to resources, and the client supports transactions, paging through search results, and inspecting request/response details. Hands-on coding sessions were encouraged to explore using the API.
This document provides an overview of a two-day training on building clinical scenarios using FHIR (Fast Healthcare Interoperability Resources). Day one focuses on reviewing key FHIR elements like resources and references, and using tools like clinFHIR to create logical models, resource models, and reference graphs. Day two will cover structured and coded data as well as generating FHIR artifacts like extensions, value sets, and profiles. Exercises are provided to help attendees work through creating a sample clinical document.
Fhir dev days_advanced_fhir_terminology_servicesDevDays
This document discusses advanced terminology services for FHIR including SNOMED CT. It provides an overview of FHIR terminology including concept maps, code systems, and value sets. It demonstrates Shrimp for browsing terminologies, Snapper for authoring FHIR resources, and discusses implicit value sets, versioning, the Expression Constraint Language, and code system operations like $subsumes and $closure. Practical tips are provided for efficient terminology server usage and handling complex value sets.
The document discusses the challenges of implementing electronic health records (EHR) in Slovenia and the benefits of using an openEHR approach. It describes how Slovenia created a Smart Healthcare & Wellbeing Cluster to deliver value through an open data platform based on openEHR standards. This has resulted in a vendor-neutral clinical data repository being used at a children's hospital in Slovenia and as part of the national health interoperability backbone. The openEHR approach is now also being used for EHR systems in Moscow, Russia.
NordForsk Open Access Reykjavik 14-15/8-2014: H2020NordForsk
This document summarizes the European Commission's policies on open access to research data and publications in Horizon 2020. Key points include:
1) Horizon 2020 will require open access to publications and encourage open access to research data through a pilot program. Projects will need to submit a data management plan and may need to deposit data in a repository.
2) The goals are to optimize the impact of publicly-funded research, enable better science, and promote economic growth and broader access.
3) Support for open access includes funding for e-infrastructure projects, training, helpdesks and guidelines on open data management.
First eStandards conference Panel of the European SDO Platformchronaki
Introduction to panel where Standards Developing Organization and National Competence Centers discuss the scope of the European SDO platform reflecting on earlier presentations.
The health crisis due to COVID-19 is shaping a new reality in which the exchange and access to health data in a secure way will be more and more necessary. In this complex challenge converge both the respect for the individual rights as well as the interests of the patients and the need to promote the research in pursuit of the public interest. To face this challenge, we can find different approaches across Europe. In this webinar, we will present the experiences of three EU-funded projects (BigMedilytics, BodyPass, and DeepHealth), besides an overview of the legal framework and recommendations to enforce both national regulations and GDPR by an expert in data privacy and security.
The Largest General Translational Informatics Public Private Partnership to DateLaura Berry
Presented at the Global Pharma R&D Informatics Congress. To find out more, visit:
www.global-engage.com
In this presentation, Jay Bergeron from Pfizer discusses eTriks: a 5 year IMI project to provide translational informatics products and services to other programs and EU Public Private Partnerships.
This document discusses health information exchange standards compliance testing via integration testing. It introduces New Zealand's approach of using an Integration Test Platform (ITP) and certification process to test standards compliance for clinical document architecture (CDA) documents. The ITP provides validation, sample instances, and test results for applications. Initial focus is on interoperability standards and providing a plug-and-play environment. Feedback on the integration as a service approach and ITP has been positive from stakeholders. The overall goals are to progress standards adoption and enable objective criteria for purchasing decisions.
Implementation and Use of ISO EN 13606 and openEHRKoray Atalag
This was the prezo for the EMBC 2013 tutorial in Osaka, Japan. Intended for an introduction to the standards and technicalities and implementation of openEHR - which is the original formalism.
The document provides information on the services and products offered by the Integrated Carbon Observation System (ICOS). ICOS generates high quality greenhouse gas observation data from over 130 monitoring stations across Europe. It processes data through a standardized pipeline from raw measurements to quality-controlled data products. ICOS also coordinates the research infrastructure, provides data management and access services, and communicates scientific findings to inform policymaking and public understanding of climate change.
European Open Science Cloud: Concept, status and opportunitiesEOSC-hub project
European Open Science Cloud: Concept, status and opportunities.
Presentation given by Gergely Sipos at the International Symposium on Grids and Clouds 2019 event in Taiwan.
OSGi Service Platform in Healthcare Service Delivery and Management - Stan Mo...mfrancis
This document discusses enabling healthcare service delivery and management through remote medical monitoring. It presents a vision for an end-to-end sensor-based architecture using networked household devices, medical sensors, and a central monitoring service connected to doctors, specialists, nurses and hospitals. The architecture would include an open, standard healthcare services platform to manage remote services and interfaces between in-home devices, healthcare providers, and medical information systems. Key issues addressed are quality of service, common device and sensor interfaces, information processing capabilities, and security. Potential solutions discussed include related research efforts but note that no open standard platform currently exists.
The need for interoperability in blockchain-based initiatives to facilitate c...Massimiliano Masi
Slides for the IEEE Blockchain Symposium in Glasgow, https://blockchain.ieee.org/standards/clinicaltrialseurope18, https://blockchain.ieee.org/standards/clinicaltrialseurope18/speakers
HANDI Summit 18 - Introducing HANDI-HOPD - Ewan DavisHANDI HEALTH
NHS England hosted the HANDI-HOPD Summit in London on the 18th September. This was attended by an invited audience of around 40 people to discuss plans to take the HANDI-HOPD platform forward to the NHS England Open Source Open Day on the 26th of November in Newcastle-Upon-Tyne where is will be launched as the Platform for NHS Code4Health.
HANDI-HOPD The HANDI Open Platform Demonstrator provides an experimental platform to demonstrate the power of emerging open standards and APIs to deliver the transformational power of the Internet to support digital health and care.
Ewan Davis introduced the HOPD, described where it fitted in the global development of open health platforms what had already been deployed and our plans for it’s development.
IHE provides a framework for implementing multiple healthcare IT standards to address specific clinical needs. It has grown from a project launched in 1998 involving healthcare providers, vendors, and standards groups. IHE defines integration profiles that specify how standards should be implemented together to enable interoperability. Examples include profiles for image and report sharing within and between healthcare enterprises using standards like DICOM and HL7.
The Continua Health Alliance publishes design guidelines to create an end-to-end plug-and-play ecosystem for personal connected health. It certifies products for compliance and promotes adoption. Continua is focused on enabling connectivity between devices, networks, and electronic health records through open standards. This allows for opportunities like remote monitoring of chronic conditions, fitness tracking, and aging in place. Continua aims to create a global market for personal connected health technologies and their integration.
The document summarizes the European Translational Research Information and Knowledge Management Service (eTRIKS) project. It describes how eTRIKS created an open-source translational data platform based on tranSMART to enable data sharing across studies. Over 30 months, eTRIKS supported over 60 projects, developing best practices for data harmonization, legal agreements, and sustainability. However, fully meeting project goals proved challenging, and the pharmaceutical industry undercommitted resources. Moving forward, eTRIKS assets will be distributed to academic partners to ensure ongoing sustainability.
IHE / RSNA Image Sharing Project - IHE Colombia Workshop (12/2014) Module 5aIHE Brasil
This document provides an overview of IHE (Integrating the Healthcare Enterprise), including:
- IHE is an international initiative that provides frameworks for standards-based interoperability between healthcare systems.
- It involves participation from various professional organizations and vendors to address real-world clinical needs.
- IHE defines integration profiles that specify how multiple standards can be coordinated to address specific use cases. Products are tested and can publish integration statements about supported profiles.
1) The document discusses integrating OpenClinica, an open-source clinical data management system, with a patient monitoring tool (PMT) to improve efficiency in clinical data management for studies conducted by DNDi and PHPT.
2) Key objectives of the integration are to reduce the time to obtain clean study data sets and decrease error rates by facilitating real-time monitoring of patient data entered into OpenClinica.
3) The methodology developed uses a community data mart to transfer study data from OpenClinica to the PMT database, allowing monitors to access collated subject data through a single interface and improving monitoring.
Information fusion and algorithm training framework objective in ICT4Life H2020 Project. Presented in IEEEHealthcom'16 within Project Alfred workshop in Munich (14-17 September 2016).
Similar to Furore devdays 2017- continua implementing fhir (20)
FHIR is a standard for exchanging healthcare information electronically. This document discusses consent models in FHIR, including attributes of consent, how consent is represented, and how to query for consent information. It provides examples of consent resources and explains the differences between representing consent in earlier versions of FHIR versus current standards.
This document discusses the DICOM standard and how it relates to FHIR for medical imaging. It provides an overview of key DICOM concepts like the image hierarchy and metadata tags. It also demonstrates how to use common DICOM tools and requests like C-FIND queries. Finally, it shows how FHIR resources like ImagingStudy can be used to represent DICOM studies and link to images accessible via DICOMweb services like WADO-RS.
Mohannad hussain community track - siim dataset & dico mweb proxyDevDays
This document discusses the SIIM Hackathon Dataset, which provides sample patient data including FHIR resources and DICOM images. It was created by the Society for Imaging Informatics in Medicine to help developers build applications using FHIR and DICOMweb standards. The freely available dataset includes health records for 5 fictional patients that can be loaded onto servers. It aims to accelerate innovation by offering realistic test data versus randomly generated data. The document also introduces the DICOM-RS Broker, which allows accessing DICOM images via DICOMweb requests through a proxy for systems that do not natively support DICOMweb.
Grahame Grieve is scheduled to give a FHIR keynote at the FHIR Dev Days 2017 conference in Amsterdam from November 15-17. The summary compares the differences between REST and messaging approaches in FHIR, noting that REST focuses on CRUD operations on single resources with client-driven orchestration, while messaging is event-driven with server-driven orchestration and allows operations beyond CRUD.
This document discusses various challenges and approaches to transforming content between different formats and standards. Some common problems addressed include implementing FHIR as a facade for an existing data store, converting specifications into FHIR profiles, and converting between FHIR and other output formats like text. Common transformation technologies include programming languages, XSLT, and mapping languages. The document also describes FHIR's built-in support for transformation through concept maps, profiles, and the FHIR mapping language.
This document provides an overview of StructureDefinition resources in FHIR. StructureDefinition resources describe the definition and validation rules for core FHIR resources, data types, logical models, and extensions. They contain metadata and constraints that are used to validate conformance to FHIR standards. The speaker discusses the key components of StructureDefinition resources, including differentials, snapshots, references between definitions, and slices.
Bryn Rhodes discusses using FHIR and clinical quality measures (CQMs) for clinical quality improvement. CQMs are measures that assess performance related to a specific process or outcome. An eMeasure is the computable, digital representation of a quality measure. eMeasures can be evaluated at the population or individual patient level. There are different types of measures that focus on processes, outcomes, structures, or patient-reported outcomes. Measures also have different scoring types and population criteria. CQMs are represented in FHIR using CQL logic and value sets to define measure populations and calculate scores. This allows CQMs to enable clinical decision support and quality improvement.
Harold Solbrig presented on representing FHIR resources as RDF and using description logic reasoning. Key points included: expressing a FHIR DiagnosticReport as RDF triples and OWL ontology, using an OWL reasoner to classify instances and derive new conclusions, and loading FHIR data into the i2b2 framework by converting to RDF. The talk also discussed post-coordinated expressions and potential uses of a fhir.schema.org vocabulary.
FHIR can be represented in RDF format. Resources are serialized as directed graphs using URIs, properties, and values. FHIR defines a metadata vocabulary for use in RDF, and a FHIR resource catalog provides the URIs for standard FHIR resources and properties. Shape expressions (ShEx) schemas validate FHIR RDF according to resource definitions. Together, these components allow FHIR data to be queried and manipulated using RDF techniques while maintaining compatibility with the JSON format. Tools exist for converting between FHIR JSON and RDF formats.
The document discusses OpenAPI (formerly known as Swagger), which is a vendor-neutral specification for describing RESTful APIs. It provides a standard, language-agnostic format used to define services and their operations. The specification aims to generate documentation, code examples, and API clients from a single API definition file. It has strong community and tooling support with over 100k visitors per month to Swagger.
Lloyd McKenzie presented on tooling for authoring FHIR implementation guides. He discussed the HL7 IG Publisher, which generates websites from ImplementationGuide resources and other artifacts. Trifolia was also covered, a web-based tool for developing and publishing FHIR profiles and implementation guides. Other tools mentioned for authoring pieces of implementation guides included Forge, ClinFHIR, and Simplifier. The goal was to provide an overview of existing options for creating FHIR implementation guide content and documentation.
The document contains information about the FHIR Developers Days 2017 conference, including the keynote speakers, dates for future DevDays conferences, upcoming webinars on FHIR, and how to find lost luggage or a poster at the event. Details are provided about Mo Alkady's talk on vendor-neutral APIs and Grahame Grieve's keynote, as well as save-the-date information for future conferences and links to register for introductory and exam review webinars on FHIR. Attendees are asked to follow the conference on Twitter and direct any questions to organizers.
This document discusses messaging in healthcare IT standards. It describes messaging as a loosely coupled paradigm where systems may not always be available to query and store-and-forward architectures are used. Messaging is triggered by business events and implies behavioral expectations between systems. It allows both synchronous request-response interactions and asynchronous messaging. Several healthcare organizations use messaging for applications like immunization record submission and prescription exchange where volume is high and systems may not always be online.
This document provides an overview of Vonk FHIR Facade, which is a set of .NET libraries for building a FHIR RESTful API facade. It discusses key components like the Vonk pipeline of middleware, services, and repositories for mapping data between a backend system and FHIR resources. The document outlines how to get started with a minimal Vonk server and provides an exercise link to a completed starter project example.
The document discusses profiling with clinFHIR. It outlines the agenda which includes reviewing key FHIR elements, clinical models, and resources. It then discusses the need to adapt FHIR to specific contexts through profiling. Profiling involves constraining resources, changing coded element bindings, and adding extensions. It provides examples of how profiling can limit names to one, change value sets, and require identifiers. The talk will cover structured and coded data including value sets and extensions. It will demonstrate creating extension definitions and profiles using clinFHIR.
This document provides an agenda and overview for the student track at the FHIR DevDays 2017 conference in Amsterdam. It introduces the student track host and provides details on the schedule which includes hackathons, presentations from various student teams, and a keynote from Google. Guidelines are provided for the hackathons and presentations. The document concludes with logistical details for the social dinner event.
The document discusses distributing clinical decision support using the FHIR Clinical Reasoning Module. It describes implementing opioid prescribing guidelines as an example, including defining relevant terminology, calculating morphine milligram equivalents, and executing the logic through a CQL engine. Key benefits include sharing decision support content and allowing different systems to execute the same logic. Challenges include customizing support for local settings and integrating with existing EHRs.
How to Manage Your Lost Opportunities in Odoo 17 CRMCeline George
Odoo 17 CRM allows us to track why we lose sales opportunities with "Lost Reasons." This helps analyze our sales process and identify areas for improvement. Here's how to configure lost reasons in Odoo 17 CRM
A workshop hosted by the South African Journal of Science aimed at postgraduate students and early career researchers with little or no experience in writing and publishing journal articles.
This presentation was provided by Steph Pollock of The American Psychological Association’s Journals Program, and Damita Snow, of The American Society of Civil Engineers (ASCE), for the initial session of NISO's 2024 Training Series "DEIA in the Scholarly Landscape." Session One: 'Setting Expectations: a DEIA Primer,' was held June 6, 2024.
How to Make a Field Mandatory in Odoo 17Celine George
In Odoo, making a field required can be done through both Python code and XML views. When you set the required attribute to True in Python code, it makes the field required across all views where it's used. Conversely, when you set the required attribute in XML views, it makes the field required only in the context of that particular view.
How to Build a Module in Odoo 17 Using the Scaffold MethodCeline George
Odoo provides an option for creating a module by using a single line command. By using this command the user can make a whole structure of a module. It is very easy for a beginner to make a module. There is no need to make each file manually. This slide will show how to create a module using the scaffold method.
it describes the bony anatomy including the femoral head , acetabulum, labrum . also discusses the capsule , ligaments . muscle that act on the hip joint and the range of motion are outlined. factors affecting hip joint stability and weight transmission through the joint are summarized.
How to Fix the Import Error in the Odoo 17Celine George
An import error occurs when a program fails to import a module or library, disrupting its execution. In languages like Python, this issue arises when the specified module cannot be found or accessed, hindering the program's functionality. Resolving import errors is crucial for maintaining smooth software operation and uninterrupted development processes.
This slide is special for master students (MIBS & MIFB) in UUM. Also useful for readers who are interested in the topic of contemporary Islamic banking.
Exploiting Artificial Intelligence for Empowering Researchers and Faculty, In...Dr. Vinod Kumar Kanvaria
Exploiting Artificial Intelligence for Empowering Researchers and Faculty,
International FDP on Fundamentals of Research in Social Sciences
at Integral University, Lucknow, 06.06.2024
By Dr. Vinod Kumar Kanvaria
Exploiting Artificial Intelligence for Empowering Researchers and Faculty, In...
Furore devdays 2017- continua implementing fhir
1. FHIR® is the registered trademark of HL7 and is used with the permission of HL7. The Flame Design mark is the registered trademark of HL7 and is used with the permission of HL7.
Amsterdam, 15-17 November | @fhir_furore | #fhirdevdays17 | www.fhirdevdays.com
Continua Implementing FHIR
Melanie Yeung, eHealth Innovation @ University Health Network
2. About Me
• Name: Melanie Yeung @melaniesyeung
• Company: eHealth Innovation,
University Health Network @Official_eHI
• Background:
• Trained as a Clinical (Biomedical) Engineer
• Member of PCHAlliance/Continua Health Alliance
• Member of IEEE Personal Health Devices Working Group
• Member of Bluetooth Medical Expert Working Group
• Co-manager of awesome dev team (@ehealthdevs)
3. My Daytime Job
• Research centre in Toronto, Canada
• Affiliated with the University of Toronto
• Unrivaled access to patients, healthcare professionals and
researchers
• 70+ scientists, engineers, project managers, psychologists,
human factors specialists, developers, designers, and students
4. Tutorial Objectives - What can you expect?
• Intro to PCHAlliance, Device
Standards, and Continua Design
Guidelines
• Device Data Upload using FHIR®
Observations
• Consuming Device Data from
Home to Hospital
• Preeclampsia Use Case
5. Personal Connected Health Alliance
• improve efficiencies and reduce cost
• advance prevention over treatment
• promote individual ownership and
control over personal health data,
including the ability to share it with
one’s healthcare provider, caregivers or
social network
• improve communication and data
exchange between patients and
providers
• create new incentives for a movement
towards personal responsibility and
engagement in one’s own health
6. Published annually, PCHAlliance’s Continua Design Guidelines define a
flexible framework for user friendly end-to-end interoperability of
personal connected health devices and systems. Continua certified
products bear the globally recognized Continua logo, which signals
market-readiness for 21st century health data exchange. The
Guidelines are recognized as an international standard by the United
Nations’ International Telecommunication Union (ITU-T) and available
free in six languages.
PCHAlliance’s flagship event, the Connected Health Conference, is
the premier international conference and expo for the exchange of
research, evidence, ideas, innovations and opportunities in
connected health. Formerly the mHealth Summit, and now in its
ninth year, the event features industry-leading keynote
presentations, dynamic programming, poster presentations, an
interactive exhibit floor, and high-value networking sessions.
www.ConnectedHealthConf.org
10. Truly Open Design Guidelines
• Continua guidelines are endorsed by a neutral leader
• International Telecommunication Union (ITU),
the global standards agency of the United Nations
• Anyone can get the Continua guidelines for FREE
• In six languages
• Download via ITU or: www.pchalliance.org/continua-design-guidelines
• Anyone can submit comments
• Via Continua or ITU
• Any party welcome to join PCHAlliance at the level of choice
• Easy market access for vendors, no vendor lock-in for users
• Contribute to new versions
11. Commercial
Ready Platforms
Continua Enabling Software Libraries (CESL)
Continua Test Tool (CTT)
Speed the
adoption
Reference source
code
Testing
Prototypes
Basis for Continua
Test Tool
Creation of
reference devices
for IOP
Existing New
Continua Code and Testing Today and Tomorrow
13. Towards adoption in Europe: Oct 2017 highlights
Denmark: (2012) National health IT strategy
sets out reliance on (Continua); roll out of
national COPD services in 2018.
Norway: (Dec. 2014) MoH announced Continua
standards as the framework for new national
remote health and social care program
Sweden (April 2016) announced open
architecture based on Continua Guidelines
European Commission: (2013) Continua
referenced alongside IHE in European eHealth
Interoperability Framework
Finland: (Oct 2017) MoH launches personal
health record in Dec 2017, expressed interest
in diabetes pilot with Continua in 2018.
eHealth Network: (May 2017) Invited six
governments to present at Malta meeting;
new MWP being prepared, led by SPMS
Austria: (Oct 2017) MoH published technical
framework directive for telemonitoring with
Continua
Catalonia (July 2017) MoH mandates
Continua compliance for glucose meters
to connect with personal health record
Portugal: (Oct 2017) SPMS will test sleep
apnea products for Continua compliance at
Boston Plugfest
15. Personal Health Devices Interface (PHD-IF)
16
Continua Design Guidelines supports
devices that can use :
• an interface based on ISO/IEEE 11073-
20601 (X73-IF)and a supported
transport technology (ZigBee, NFC,
USB and Bluetooth BR/EDR)
• an interface based on a Bluetooth LE
(BLE-IF) as transport, technology and
one or more (application level)
services and profiles defined by
Bluetooth Special Interest Group (SIG).
16. Institute of Electrical and Electronics Engineering
• IEEE-11073 Personal Health Devices
(PHD) Working Group
• Focus on interoperability of personal
health devices for personal use
• Transport agnostic
• Open group, including both industry and
academic participation
• Easy access and low cost to published
standards
17. IEEE 11073- PHD’S FOCUS
Agent (aka. Sensor)
• Exchange Protocol + Device
Specializations
• Domain Information Model (DIM)
• Service Model
• Communication Model
• Device-specific information
• Supported Domains:
• Disease Management
• Health and Fitness
• Aging Independence
Manager (aka. Client)
18. Domain Information Model (DIM)
• Describes the device and physiological data
• Object oriented model
• No requirement to implement in object oriented language
• Generic set of classes created
• Classes define attributes and methods
• Attribute type defined in ASN.1 (language for abstract modeling of
data and interactions)
• Objects are tailored using the attributes
• Attributes may be:
• Mandatory, optional, or conditional
• Static or dynamically changing
20. IEEE 20601: Objects
Sensor
PM-Store Object ‘n’
Agent’s hard disk
*optional*
MDS Object
Device’s bureaucratic and system
information
*must have*
Metric Object ‘k’
Describes a measurement
(e.g. weight, status, waveform)
*optional*
Scanner Object ‘m’
Formats and groups for data
transmission (eventing)
*optional*
22. -00103 Technical Report - Overview
Device Specializations
-10404
Pulse
Oximeter
-10407
Blood
Pressure
-10408
Thermo-
meter
-10415
Weighing
Scale
-10417
Glucose
Meter
-10441
Cardio
-10419
Insulin
Pump
-10425
CGM
-104xx
…
-20601 Optimized Exchange Protocol
Communication Protocols
NFC Bluetooth BR/EDR USB 2.0 ZigBee
OSILayers4-5OSILayers6-7
IEEE Standards and Specializations
NFC PHD class Bluetooth HD profile USB PHD class ZigBee HC class
23. Completed Standards (20 / 29)
• IEEE Std 11073-10404 Dev specialization – Pulse oximeter
• IEEE Std 11073-10406 Dev specialization – Basic ECG
• IEEE Std 11073-10407 Dev specialization – Blood pressure monitor
• IEEE Std 11073-10408 Dev specialization – Thermometer
• IEEE Std 11073-10415 Dev specialization – Weighing scale
• IEEE Std 11073-10417 Dev specialization – Glucose meter + Revision +
Revision
• IEEE Std 11073-10418 Dev specialization – INR (blood coagulation) +
Corrigendum
• IEEE Std 11073-10419 Dev specialization – Insulin Pump +Revision
• IEEE Std 11073-10420 Dev specialization – Body composition analyzer
• IEEE Std 11073-10421 Dev specialization – Peak flow
• IEEE Std 11073-10422 Dev specialization – Urine analyzer
• IEEE Std 11073-10424 Dev specialization – SABTE +Corrigendum
• IEEE Std 11073-10425 Dev specialization – CGM +Revision
• IEEE Std 11073-10427 Dev specialization – Power Status Monitor(PSM)
• IEEE Std 11073-10441 Dev specialization – Cardiovascular + Revision
• IEEE Std 11073-10442 Dev specialization – Strength fitness equip
• IEEE Std 11073-10471 Dev specialization – Activity hub
• IEEE Std 11073-10472 Dev specialization – Medication monitor
• IEEE Std 11073-20601 Optimized exchange protocol + Amd + Rev+Cor
• IEEE Std 11073-00103 Personal health device communication -
Overview
24. Projects Underway (12)
• IEEE P11073-10426 Dev specialization – Home Healthcare Environment
Ventilator (New)
• IEEE P11073-20601 Optimized exchange protocol (Revision)
• IEEE P11073-10404 Dev specialization – Pulse Oximeter (Revision)
• IEEE P11073-10407 Dev specialization – Blood Pressure Monitor (Revision)
• IEEE P11073-10408 Dev specialization – Thermometer (Revision)
• IEEE P11073-10415 Dev specialization – Weighing Scale (Revision)
• IEEE P11073-10420 Dev specialization – Body composition analyzer (Revision)
• IEEE P11073-10406a Dev specialization – Basic ECG (Revision)
• IEEE P11073-10471a Dev specialization – AI Living Hub (Revision)
• IEEE P11073-10425 Dev specialization – Continuous Glucose Meter (Revision)
• IEEE P11073-10419 Dev specialization – Glucose Meter (Revision)
• IEEE P11073-10428 Dev specialization – Electronic Stethoscope
26. Bluetooth Special Interest Group (SIG)
• Bluetooth SIG Medical Working Group
• Scope: to improve the user experience
for Bluetooth-enabled medical,
healthcare, and fitness devices
• Industry-focused, closed group
(membership required to develop
standards)
28. Bluetooth Generic Attributes (GATT) Specifications
• GATT profile
• describes a use case, roles, and general behaviors based on the GATT
functionality, enabling extensive innovation while maintaining full
interoperability with other Bluetooth® devices.
• GATT services
• collections of characteristics and relationships to other services that
encapsulate the behavior of part of a device.
33. Continua Device Data to FHIR® server Upload Objectives
• Ensure no loss of information
• Equivalent to what is available via IHE PCD-01 upload
• Represent information using HL7 Defined FHIR® resources
• Support secure, interoperable uploads from Personal Health Gateway
to Health & Fitness Service
• https transport
• OAuth-2 based authorization framework
• Allow consumer choice in PHGs
35. Service-IF
37
Continua Design Guidelines specify
three implementations for
uploading HL7 V2.6 Observations
payloads:
• IHE PCD-01 message packaged in
SOAP and authenticated using
SAML,
• HL7 FHIR Resources via REST and
OAuth, and
• IHE PCD-01 message sent over
HL7 hData Framework and hData
REST transport binding.
36. Service-IF
38
Continua Design Guidelines specify
three implementations for
uploading HL7 V2.6 Observations
payloads:
• IHE PCD-01 message packaged in
SOAP and authenticated using
SAML,
• HL7 FHIR Resources via REST and
OAuth, and
• IHE PCD-01 message sent over
HL7 hData Framework and hData
REST transport binding.
HL7 v.2.6
HL7 v.3.0HL7 FHIR STU3
37. 11073 “MDC” Device Info Model (highly simplified!)
Physical Top-Level Device Info (ID, H/W & S/W versions, battery …)
Medical Device
System (MDS)
Virtual Medical
Device (VMS)
Channel
Metric
Device Subsystem Info (BP, ECG, temp …)
Related Parameter Group Info (ECG Channel #1, #2, #3, …)
Parameter Metadata Info (Datatype independent info, e.g. period)
1..*
1..*
1..*
Numerics /
Enumerations /
Waves
1..1
Parameter Info (Value + datatype-specific elements)
Defined in ISO/IEEE 11073-10201 & 11073-20601
39. 11073 “MDC” PHD Model FHIR Mapping (current)
Medical Device
System (MDS)
Metric
(Abstract)
Numerics /
Enumerations /
Waves
1..*
1..1
Patient
Observation
DeviceComponent
(PHD MDS Profile)
40. Continua Personal Health Device Measurement Upload
• Three FHIR defined resources
1. the Patient Resource,
2. the DeviceComponent Resource,
3. the Observation Resource.
42
Observation (Metric OBXes)
Components: (OBX-facets)
DeviceComponent (PHG)
Patient (PID)
Bundle
DeviceComponent (sensor)
HTTP POST header
41. Patient Resource
• Managing Patient Identity
• PHG must properly reference the patient resource in any observation
resource being uploaded
• In the FHIR protocol this is done by having the PHG provide the Logical ID of
the patient resource to the FHIR server.
• Potential challenges in obtaining the Logical ID of the patient resource
for the PHG
• PHG must know the Logical ID of the Patient Resource, or
• must be able to provide a Patient Designator which will allow the Logical ID to
be located
42. Patient Resource
(Scenario – Logical ID is provided)
• Logical ID is
communicated to the
H&FS party responsible
for configuring the PHG
in the home
environment.
• PHG is configured with
the appropriate Logical
Identification of the
Patient Resource
43. Patient Designator
(Scenario – Logical ID is not provided)
Patient Designator is:
• other information, which identifies the patient
• can represent a wide range of different forms of patient identity, appropriate to different
situations
• contains information about who the assigning authority is, and how the patient is identified
by that assigning authority
• is used to establish the identity of the patient in the uploading of a measurement
• Patient Designator is can be used to generate a FHIR Patient Resource
1) PHG takes the responsibility of specifying the Logical ID of this resource, which must be
unique when used in the FHIR server
2) PHG obtains from HF&S the generated Logical ID by identifying the Patient Resource using
the Patient Designator
44. DeviceComponent Resource
• Characteristics, operational status and capabilities for a component of a
healthcare device. Used to describe PHG or sensor attributes such as:
• System ID
• Device Type
• Production specification
• Regulation certification information
• Time synchronization/capabilities
• The Logical ID of the DeviceComponent Resource shall be unique on the H&F and
should be set to IEEE systemId-Transport Address or if not available, then should
be set to UUID
46
45. Observation Resource
• mapping of [ISO/IEEE 11073-20601] to FHIR is primarily through the
IEEE nomenclature codes
• codes describe what the measurement is, the units, and can be the
measurement itself.
• mapped to the appropriate FHIR CodeableConcept elements
48. Use Case Overview
• Annie is a 31 y.o. female, 1st pregnancy
• Asymptomatic hypertension (DBP > 90-99mmHg SBP > 140-
149mmHg) and proteinuria (conc. 30mg/dl >1+ dipstick) > 20wk
gestation
• She delivered a healthy 7lbs 5 oz baby boy 1/29/2017 at 19:50
following induction at 37 + 6 weeks.
• Infant was delivered vaginally without complications, APGARS 8/9.
Infant and mother transitioned normally to the postpartum ward and
were discharged to home on Hospital Day 2.
50
49. Initial diagnosis
• Annie first presented at wk35 prenatal visit with +3
proteinuria dipstick
• Follow-up lab results urinalysis showed Protein:creatinine
863 mg/mmol (norm <30mg/mmol)
• Home blood pressure readings (taken every 6 hours) ranged
from 98-114 / 65-76 mmHg.
• Daily home dipstick shows –ve results
51
50. Home monitoring
• On the fourth day, however, her BP spiked to 142/90.
• This data was analyzed by the CDS system that automatically sent her an SMS
text message reminding her that she was to repeat the measurement every
hour for 3 hours.
• When repeating the measurements, her BPs are still 140-149 / 90-99.
• Following these readings, the CDS concludes that Annie should begin
start taking her blood pressure every 4 hours.
• The system sends an SMS text to Annie and an EMR alert to her provider
notifying them of the recommendation.
• Upon receiving the alert, Annie’s provider logs into the EMR and reviews the
vital signs obtained at home.
52
51. Analysis and Escalation
• Over the next 48 hours, Annie dutifully records her blood pressure.
• Annie’s blood pressures continue to trend up, now ranging between
150-155 / 100-108.
• CDS concludes that Annie needs to be evaluated and stabilized as
an inpatient.
• System sends an SMS text to Annie and a traditional EMR alert to
her provider notifying them of the recommendation.
• Upon receiving the alert, Annie’s provider logs into the EMR,
reviews the home vital signs before arranging for her admission.
53
52. Hospitalization
• Upon admission, Annie is monitored every hour x 2 using a hospital
blood pressure device that also transmits its data to the CDS system.
• The new monitor confirms that Annie’s blood pressure is ranging
between 150-155 / 100-108.
• CDS system alerts her provider, recommending that her therapy be
augmented with oral medication.
• Following this addition to her oral therapy, Annie’s blood pressure
normalizes over the next 48 hours to 100-125 / 65-80 mmHg and she
is subsequently discharged to complete her home remote monitoring.
54
53. Noninvasive Blood Pressure Monitor Device
• Typically two numbers reported
• Systolic pressure: contraction of the
heart
• Diastolic pressure: relaxation of the
heart
• Third number may be available
• Mean arterial pressure
• Units of measurement (mmHg)
• Pulse Rate (/min) *optional
Let’s begin. How many of you have heard of PCHA? Or Continua?
What is this organization?
The Personal Connected Health Alliance (PCHAlliance) aims to make health and wellness an effortless part of daily life. The PCHAlliance, a non-profit organization formed by HIMSS, believes that health is personal and extends beyond healthcare. The PCHAlliance mobilizes a coalition of stakeholders to realize the full potential of personal connected health. PCHAlliance members are a vibrant ecosystem of technology and life sciences industry icons and innovative, early stage companies along with governments, academic institutions, and associations from around the world.
Strives to… improve, advance, promote, create
PCHA does this through two major initiatives: Connected Health Conference and Continua Design guidelines
To support its vision, the PCHAlliance convenes the global personal connected health community at the annual Connected Health Conference, the premier international event for the exchange of research, evidence, ideas, innovations and opportunities in personal connected health.
The PCHAlliance publishes and promotes the global adoption of the Continua Design Guidelines, an open framework for user-friendly, interoperable health data exchange in personal connected health. The Continua Design Guidelines are recognized by the International Telecommunication Union (ITU), an agency of the United Nations, as the international standard for safe, secure, and reliable exchange of data to and from personal health devices
eco-system of open plug-and-play interoperable personal connected health devices and services which are validated in accordance with the Continua certification program.
Personal health devices and gateways in the home connected to services
How do we enable the transfer of data from E2E? Leveraging existing industry standards and providing guidance to secure data through three interfaces. Plug-n-play guaranteed when each of the services are Continua certified
Technical E2E architecture can be described in these 3 interfaces
PHD Interface connecting a Personal Health Device to a PHG capturing sensor data from a patient
Services interface – collecting, aggregating and
Healthcare Information System Interface – combining data with other information
These interfaces and ability to achieve E2E interoperability are described through a series of documents that combined produces the CDG.
not a proprietary platform
Accepted by the International Telecommunication Union, the global standards agency of the United Nations, and can be downloaded for FREE in six languages via ITU or in English via www.continuaalliance.org
and creates new market access
Note on languages is it 6+English? (so 7 total) or 6 including English. Mentioning English seems a bit odd, right?
CESL code base is intended to
Speed the adoption of Continua by assisting members in product development via reference source code
Enable testing of prototypes against CESL reference implementations
Enable the Continua Test Tool by providing a basis on which to build
Enable the creation of reference devices for use in Plugfests and manual test programs
Development, Test & Certification
Continua test tools save time and resources during development
Certified Experts (“CCEs”) available to support development and certification
“Plugfests” allow real world testing in a trusted, constructive environment
Continua CertifiedTM logo
Individual: ensures interoperability
Manufacturers: provides competitive advantage
>100 health devices and services certified
Wins:
Finland (pop 5.5m): MoH interest in diabetes pilot with Continua in 2018
Austria (pop 8.6m): MoH publishes framework directive for telemonitoring
Denmark (pop 5.7m): National COPD rollout expected in early 2018
Catalonia (pop 7.5m): MoH mandated Continua compliance for glucose meters (July 2017)
India (pop 1.3bn): PCHAlliance represented in the standards body BIS - MHD 17.
Opportunities
eHealth Network will roll out new Multiannual Work Plan in 2018
WHO/ITU European mHealth Hub project: PCHAlliance included in several proposals
Digital Health Society process including task force for interoperability
3 interfaces
Devices certified as Continua Compliant can feed data into any other systems that are continua certified
3.2.16 Continua personal health devices interface (PHD-IF): The Continua PHD-IF connects
one or more personal health device (e.g., sensor/actuator) client components to one or more
personal health device (sensor/actuator) service components using transport media such as USB,
BLE, Bluetooth, ZigBee or NFC. Examples of sensor service components include glucose meters,
weighing-scales and heart rate monitors.
3.2.17 Continua services interface: The Continua services interface is an interface between a
personal health gateway (e.g., smart phone, tablet or dedicated hub) and a health and fitness service
(e.g., disease management service, ageing independently service or wellness service). The health
and fitness service could be hosted in the cloud. IP based connectivity is assumed between the
personal health gateway and the health and fitness service and Continua focuses on defining the
behavior of the OSI layers above IP.
3.2.18 Continua healthcare information system interface (HIS-IF): HIS-IF is an interface
between a health and fitness service (e.g., disease management service, ageing independently
service and wellness service) and a healthcare information system (HIS) such as an electronic
medical record (EMR), an electronic health record (EHR) or a pharmacy information system).
For those of you unfamiliar,
IEEE has a number of different working groups devoted to standards, the one we are involved with is specifically for developing standards for Personal Health Device - 11073
Focus on data elements, and stays transport agnostic
Open group/ Open participation
4.2.2 Domain information model
The DIM is a hierarchical model that describes an agent as a set of objects. These objects and their attributes represent the elements that control behavior and report on the status of the agent and data that an agent can communicate to a manager. Communication between the agent and the manager is defined by the application protocol in IEEE Std 11073-20601.
4.2.3 Service model
The service model defines the conceptual mechanisms for the data exchange services. Such services are mapped to messages that are exchanged between the agent and the manager. Protocol messages within the ISO/IEEE 11073 series of standards are defined in ASN.1. The messages defined in IEEE Std 11073-20601 can coexist with messages defined in other standard application profiles defined in the ISO/IEEE 11073 series of standards.
4.2.4 Communication model
In general, the communication model supports the topology of one or more agents communicating over logical point-to-point connections to a single manager. For each logical point-to-point connection, the dynamic system behavior is defined by a connection state machine as specified in IEEE Std 11073-20601.
*Capabilities described are typical of respective devices, however they are not universal rules
Agent has objects to describe its features
Focus on interoperability of personal health devices (PHD) for personal use rather than in-hospital
Transport agnostic
Open group, including both industry and academic participation
Scope: improve the user experience for Bluetooth-enabled medical, healthcare, and fitness devices.
Critical for Bluetooth LE devices (not covered by IEEE-11073 standards)
Industry-focused, closed group (Associate or Promoter membership required)
Pair of specs
profile describes a use case, roles and general behaviors based on the GATT functionality. Services are collections of characteristics and relationships to other services that encapsulate the behavior of part of a device. This also includes hierarchy of services, characteristics and attributes used in the attribute server.
The top level of the hierarchy is a profile. A profile is composed of one or more services necessary to fulfill a use case. A service is composed of characteristics or references to other services. Each characteristic contains a value and may contain optional information about the value. The service and characteristic and the components of the characteristic (i.e., value and descriptors) contain the profile data and are all stored in Attributes on the server.
Descriptors: value
Properties:
Value: opaque structured
IEEE and Bluetooth are two separate standards that target different implementations
IEEE is a application layer protocol
BT are both transport and application layer
Can transcode the BT data into IEEE to make it interoperable before extending it to HL7
3 interfaces
Devices certified as Continua Compliant can feed data into any other systems that are continua certified
3.2.16 Continua personal health devices interface (PHD-IF): The Continua PHD-IF connects
one or more personal health device (e.g., sensor/actuator) client components to one or more
personal health device (sensor/actuator) service components using transport media such as USB,
BLE, Bluetooth, ZigBee or NFC. Examples of sensor service components include glucose meters,
weighing-scales and heart rate monitors.
3.2.17 Continua services interface: The Continua services interface is an interface between a
personal health gateway (e.g., smart phone, tablet or dedicated hub) and a health and fitness service
(e.g., disease management service, ageing independently service or wellness service). The health
and fitness service could be hosted in the cloud. IP based connectivity is assumed between the
personal health gateway and the health and fitness service and Continua focuses on defining the
behavior of the OSI layers above IP.
3.2.18 Continua healthcare information system interface (HIS-IF): HIS-IF is an interface
between a health and fitness service (e.g., disease management service, ageing independently
service and wellness service) and a healthcare information system (HIS) such as an electronic
medical record (EMR), an electronic health record (EHR) or a pharmacy information system).
Continua has developed a mapping for 20601 regardless of specialization. What has been mapped to FHIR resources are the attributes of Metric objects. So it does not make any difference what the object represents (glucose concentration, body mass, steps, blood pressure, etc.
The MDS static attributes describing the device have been mapped to Device and DevcieComponent resources. The Coincident Time stamp Observation handles the 20601 time properties of the sensor. Dynamic/Observational MDS attributes (like the battery level) are mapped to Observations
Demographic and administrative information about the patient.
Links the measurement information to the patient
The Logical ID of the Patient Resource identifies the Patient Resource, and indirectly the patient
PHG must know the Logical ID of the Patient Resource, or must be able to provide a Patient Designator which will allow the Logical ID to be located
Interoperibilty of medical device data from the home to hospital.
Managing chronic conditions > Disease management service
Aging and Wellness
Health and Fitness
These are only a few of the possibilities. Continua data from all types of sensors is possible and the ability to aggregate and secure the data downstream as a conduit into the EHR will fully open up the use-case spectrum, such that any organization with a vision for solving real solutions can realize that vision……………....................
Diabetes:
Glucose meter, Continuous Glucose Monitor, Insulin Pump, Weight Scale, Blood Pressure Monitor, Heart rate monitor (optional)
Hypertension:
Blood Pressure Monitor, Weight Scale, Heart Rate Monitor
Heart Failure:
Weight Scale, Blood Pressure Monitor, ECG (Electrocardiogram), Heart rate monitor
COPD:
Spirometer, Peak Flow, Thermometer, Pulse Oximeter, Heart rate monitor, CO2 monitor (optional)
Health & Fitness and many other use-cases …