[{"innerBlocks":[],"name":"core\/freeform","postId":125842,"blockType":{"name":"core\/freeform","keywords":[],"attributes":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"providesContext":[],"usesContext":[],"selectors":[],"supports":{"className":false,"customClassName":false,"reusable":false},"styles":[],"variations":[],"apiVersion":3,"title":"Classic","description":"Use the classic WordPress editor.","category":"text"},"originalContent":"In the 1990s, the use of HL7v2.x messaging standards became widespread, and to simplify the development of connections (primarily) between departmental systems within the four walls, the healthcare integration engine was born.The primary model of data exchange supported was and is an event-based push model of high-volume, low-latency transactions. The integration engine gave healthcare organizations one place to build connections, to secure those connections, to monitor those connections, and a locus of governance and accountability for keeping the data flowing at scale.In the early 2000s, in response to the need to efficiently exchange summarized clinical information between EHRs, the Continuity of Care Document (CCD) and, later, the Consolidated Clinical Document Architecture (C-CDA) were created.

The primary exchange model for CCDs was and remains query\/reply, or a \u201cpush\u201d leveraging secure email (\u201cDirect\u201d), delivering often massive C-CDA clinical summaries produced by an EHR.Neither of these interoperability models is well suited to provide just enough information, when needed, for the burgeoning ecosystem of internet-based applications that we see today. These apps grew up in the world of the internet, web and mobile applications, and expect to connect via Application Programming Interfaces (APIs), leveraging ubiquitous standards such as REST transactions (think HTTPs), in human readable JSON or XML formats, with readily discoverable \u201cdescriptions\u201d of the APIs understandable to developers and connecting applications.To meet this need, the HL7 Fast Healthcare Interoperability Resources (FHIR) standard was created to enable secure exchange of just enough information on demand or via subscription over the internet in packets of clinically related data termed \u201cResources\u201d in self-describing FHIR APIs. This new FHIR API standard is well suited for supporting rapid innovation and the flattening of the healthcare ecosystem.Today, we are witnessing an explosion of applications and trading partners leveraging FHIR to support health at home, remote monitoring, personal wearables, telehealth, retail health, payer-provider connectivity and patient-mediated exchange, such as with the Apple Health record.So, we have made a lot of progress, but much more needs to be made. These three things stand out.A point of control and governance<\/b>With the explosion of the application ecosystem, we have moved away from having a scalable and flexible locus of control, governance, and visibility into one of the organization\u2019s most valuable assets\u2014its data. Healthcare organizations are faced with making myriad application to application connections across multiple interoperability paradigms, HL7v2, C-CDA, FHIR and other APIs, involving both new and legacy systems, inside and outside the organization. This is a recipe for chaos and unintended consequences and cries out for a layer of control and governance of these data flows. Connecting operational systems<\/b>The progress in interoperability has been most visible in the world of clinical data and EHRs. Healthcare, of course, has other critical operational systems, such as supply chain, finance, human capital, enterprise asset management, and customer relationship management. To reach the Quadruple Aim\u2014to optimize quality, cost, population health, and \u201cprovider\u201d or staff engagement and retention\u2014these operational systems need to be connected and workflows streamlined.More easily combining and doing things with that data<\/b>To streamline workflows, we need to move away from disparate, single-purpose apps and toward smaller, pluggable \u201cservices\u201d enabling us to present information in context with a more personalized experience and workflow. This also enables us to embed analytics and artificial intelligence (AI), like voice navigation, alerting, and process automation, not as separate periodic exercises or reports, but in context. This level of integration and automation will enable workers, for example, to locate equipment quickly, to be confident that the right supplies are always available, to have analysis at their fingertips, and be freed from paper, phone, and fax processes. Such integration depends on having a highly scalable and secure platform supporting the flow and reuse of clinical and operational data, including data from Internet of Things (IOT) and legacy systems.We have made tremendous progress in interoperability. The transformation of healthcare and progress toward the Quadruple Aim will depend on enabling the secure flow of data, at scale, across all elements of the healthcare enterprise and across a very dynamic healthcare ecosystem. For this to be achieved, healthcare organizations need more than an integration engine platform for connected health capable of flexibly managing and governing data flow at scale.","saveContent":"In the 1990s, the use of HL7v2.x messaging standards became widespread, and to simplify the development of connections (primarily) between departmental systems within the four walls, the healthcare integration engine was born.The primary model of data exchange supported was and is an event-based push model of high-volume, low-latency transactions. The integration engine gave healthcare organizations one place to build connections, to secure those connections, to monitor those connections, and a locus of governance and accountability for keeping the data flowing at scale.In the early 2000s, in response to the need to efficiently exchange summarized clinical information between EHRs, the Continuity of Care Document (CCD) and, later, the Consolidated Clinical Document Architecture (C-CDA) were created.The primary exchange model for CCDs was and remains query\/reply, or a \u201cpush\u201d leveraging secure email (\u201cDirect\u201d), delivering often massive C-CDA clinical summaries produced by an EHR.Neither of these interoperability models is well suited to provide just enough information, when needed, for the burgeoning ecosystem of internet-based applications that we see today. These apps grew up in the world of the internet, web and mobile applications, and expect to connect via Application Programming Interfaces (APIs), leveraging ubiquitous standards such as REST transactions (think HTTPs), in human readable JSON or XML formats, with readily discoverable \u201cdescriptions\u201d of the APIs understandable to developers and connecting applications.To meet this need, the HL7 Fast Healthcare Interoperability Resources (FHIR) standard was created to enable secure exchange of just enough information on demand or via subscription over the internet in packets of clinically related data termed \u201cResources\u201d in self-describing FHIR APIs. This new FHIR API standard is well suited for supporting rapid innovation and the flattening of the healthcare ecosystem.Today, we are witnessing an explosion of applications and trading partners leveraging FHIR to support health at home, remote monitoring, personal wearables, telehealth, retail health, payer-provider connectivity and patient-mediated exchange, such as with the Apple Health record.So, we have made a lot of progress, but much more needs to be made. These three things stand out.A point of control and governance<\/b>With the explosion of the application ecosystem, we have moved away from having a scalable and flexible locus of control, governance, and visibility into one of the organization\u2019s most valuable assets\u2014its data. Healthcare organizations are faced with making myriad application to application connections across multiple interoperability paradigms, HL7v2, C-CDA, FHIR and other APIs, involving both new and legacy systems, inside and outside the organization. This is a recipe for chaos and unintended consequences and cries out for a layer of control and governance of these data flows. Connecting operational systems<\/b>The progress in interoperability has been most visible in the world of clinical data and EHRs. Healthcare, of course, has other critical operational systems, such as supply chain, finance, human capital, enterprise asset management, and customer relationship management. To reach the Quadruple Aim\u2014to optimize quality, cost, population health, and \u201cprovider\u201d or staff engagement and retention\u2014these operational systems need to be connected and workflows streamlined.More easily combining and doing things with that data<\/b>To streamline workflows, we need to move away from disparate, single-purpose apps and toward smaller, pluggable \u201cservices\u201d enabling us to present information in context with a more personalized experience and workflow. This also enables us to embed analytics and artificial intelligence (AI), like voice navigation, alerting, and process automation, not as separate periodic exercises or reports, but in context. This level of integration and automation will enable workers, for example, to locate equipment quickly, to be confident that the right supplies are always available, to have analysis at their fingertips, and be freed from paper, phone, and fax processes. Such integration depends on having a highly scalable and secure platform supporting the flow and reuse of clinical and operational data, including data from Internet of Things (IOT) and legacy systems.We have made tremendous progress in interoperability. The transformation of healthcare and progress toward the Quadruple Aim will depend on enabling the secure flow of data, at scale, across all elements of the healthcare enterprise and across a very dynamic healthcare ecosystem. For this to be achieved, healthcare organizations need more than an integration engine platform for connected health capable of flexibly managing and governing data flow at scale.","order":0,"get_parent":{},"attributes":[],"attributesType":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"dynamicContent":""}]

Beyond integration: how APIs can form a platform for connected health

More for you