Building a serverless cloud-native EDI solution with Amazon

海外精选
海外精选的内容汇集了全球优质的亚马逊云科技相关技术内容。同时,内容中提到的“AWS” 是 “Amazon Web Services” 的缩写,在此网站不作为商标展示。
0
0
{"value":"Electronic data interchange (EDI) is a technology that exchanges information between organizations in a structured digital form based on regulated message formats and standards. EDI has been used in healthcare for decades on the payer side for determination of coverage and benefits verification. There are different standards for exchanging electronic business documents, like [ American National Standards Institute X12 (ANSI)](https://www.ansi.org/), Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT), and Health Level 7 (HL7).\n\nHL7 is the standard to exchange messages between enterprise applications, like a Patient Administration System and a Pathology Laboratory Information. However, HL7 messages are embedded in Health Insurance Portability and Accountability Act (HIPAA) X12 for transactions between enterprises, like hospital and insurance companies.\n\nHIPAA is a federal law that required the creation of national standards to protect sensitive patient health information from being disclosed without the patient’s consent or knowledge. It also mandates healthcare organizations to follow a standardized mechanism of EDI to submit and process insurance claims.\n\nIn this blog post, we will discuss how you can build a serverless cloud-native EDI implementation on Amazon Web Services using the Edifecs XEngine Server.[ Edifecs XEngine Server](https://www.edifecs.com/products/xengine-server)\n#### **EDI implementation challenges**\nDue to its structured format, EDI facilitates the consistency of business information for all participants in the exchange process. The primary EDI software that is used processes the information and then translates it into a more readable format. This can be imported directly and automatically into your integration systems. Figure 1 shows a high-level transaction for a healthcare EDI process.\n\n![image.png](https://dev-media.amazoncloud.cn/75406f69bf614bb491c900b0dbaf9e1e_image.png)\n\nFigure 1. EDI Transaction Sets exchanges between healthcare provider and payer\nAlong with the implementation itself, the following are some of the common challenges encountered in EDI system development:\n\n1. **Scaling.** Despite the standard protocols of EDI, the document types and business rules differ across healthcare providers. You must scale the scope of your EDI judiciously to handle a diverse set of data rules with multiple EDI protocols.\n2. **Flexibility in EDI integration.** As standards evolve, your EDI system development must reflect those changes.\n3. **Data volumes and handling bad data.** As the volume of data increases, so does the chance for errors. Your storage plans must adjust as well.\n4. **Agility.** In healthcare, EDI handles business documents promptly, as real-time document delivery is critical.\n5. **Compliance**. State Medicaid and Medicare rules and compliance can be difficult to manage. HIPAA compliance and CAQH CORE certifications can be difficult to acquire.\n#### **Solution overview and architecture data flow**\nProviders and Payers can send requests as enrollment inquiry, certification request, or claim encounter to one another. This architecture uses these as source data requests coming from the Providers and Payers as flat files (.txt and .csv), Active Message Queues, and API calls (submitters).\n\nThe steps for the solution shown in Figure 2 are as follows:\n**1.** Flat, on-premises files are transferred to [Amazon Simple Storage Service](https://aws.amazon.com/cn/s3/?trk=cndc-detail) (S3) buckets using Amazon Web Services Transfer Family **(2)**.\n**3.** Amazon Web Services Fargate on Amazon Elastics Container Service ([Amazon ECS](https://aws.amazon.com/cn/ecs/?trk=cndc-detail)) runs Python packages to convert the transactions into JSON messages, then queues it on [Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) **(4)**.\n**5.** Java Message Service (JMS) Bridge, which runs Apache Camel on Fargate, pulls the messages from the on-premises messaging systems and queues them on [Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) **(6)**.\n**7.** Fargate also runs programs to call the on-premises API or web services to get the transactions and queues it on [Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) **(8).**\n**9.** [Amazon CloudWatch](https://aws.amazon.com/cn/cloudwatch/?trk=cndc-detail) monitors the queue depth. If queue depth goes beyond a set threshold, CloudWatch sends notifications to the containers through [Amazon Simple Notification Service](https://aws.amazon.com/cn/sns/?trk=cndc-detail) (SNS) **(10).**\n**11.** [Amazon SNS](https://aws.amazon.com/cn/sns/?trk=cndc-detail) triggers Amazon Web Services Lambda, which adds tasks to Fargate **(12),** horizontally scaling it to handle the spike.\n**13**. Fargate runs Python programs to read the messages on [Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) and uses PYX12 packages to convert the JSON messages to EDI file formats, depending on the type of transactions.\n**14.** The container also may queue the EDI requests on different queues, as the solution uses multiple trading partners for these requests.\n**15.** The solution runs Edifecs XEngine Server on Fargate with Docker image. This polls the messages from the queues previously mentioned and converts them to EDI specification by the trading partners that are registered with Edifecs.\n**16.** Python module running on Fargate converts the response from the trading partners to JSON.\n**17.** Fargate sends JSON payload as a POST request using [Amazon API Gateway](https://aws.amazon.com/cn/api-gateway/?trk=cndc-detail), which updates requestors’ backend systems/databases **(12) **that are running microservices on [Amazon ECS](https://aws.amazon.com/cn/ecs/?trk=cndc-detail) **(11)**.\n**18.** The solution also runs [Elastic Load Balancing](https://aws.amazon.com/cn/elasticloadbalancing/?trk=cndc-detail) to balance the load across the [Amazon ECS](https://aws.amazon.com/cn/ecs/?trk=cndc-detail) cluster to take care of any spikes.\n**19.** [Amazon ECS](https://aws.amazon.com/cn/ecs/?trk=cndc-detail) runs microservices that uses [Amazon RDS](https://aws.amazon.com/cn/rds/?trk=cndc-detail) **(20)** for domain specific data.\n\n![image.png](https://dev-media.amazoncloud.cn/fb91062bc25a41cfb75301ac61925e9b_image.png)\n\nFigure 2. EDI transaction-processing system architecture on Amazon Web Services\n#### **Handling PII/PHI data**\nThe EDI request and response file includes protected health information (PHI)/personal identifiable information (PII) data related to members, claims, and financial transactions. The solution leverages all Amazon Web Services services that are HIPAA eligible and encrypts data at rest and in-transit. The file transfers are through FTP, and the on-premises request/response files are Pretty Good Privacy (PGP) encrypted. The [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) buckets are secured through bucket access policies and are AES-256 encrypted.\n\n[Amazon ECS](https://aws.amazon.com/cn/ecs/?trk=cndc-detail) tasks that are hosted in Fargate use ephemeral storage that is encrypted with AES-256 encryption, using an encryption key managed by Fargate. User data stored in [Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) is encrypted at rest. [Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) encryption at rest provides enhanced security by encrypting data using encryption keys stored in the Amazon Web Services Key Management Service. All connections between [Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) brokers use Transport Layer Security to provide encryption in transit. All APIs are accessed through API gateways secured through [ Amazon Cognito](https://aws.amazon.com/cognito/). Only authorized users can access the application.\nThe architecture provides many benefits to EDI processing:\n\n- **Scalability.** Because the solution is highly scalable, it can speed integration of new partner/provider requirements.\n- **Compliance.** Use the architecture to run sensitive, HIPAA-regulated workloads. If you plan to include PHI (as defined by HIPAA) on Amazon Web Services services, first accept the Amazon Web Services Business Associate Addendum (Amazon Web Services BAA). You can review, accept, and check the status of your Amazon Web Services BAA through a self-service portal available in Amazon Web Services Artifact. Any Amazon Web Services service can be used with a healthcare application, but only services covered by the Amazon Web Services BAA can be used to store, process, and transmit protected health information under HIPAA.\n- **Cost effective.** Though serverless cost is calculated by usage, with this architecture you save as your traffic grows.\n- **Visibility.** Visualize and understand the flow of your EDI processing using [Amazon CloudWatch](https://aws.amazon.com/cn/cloudwatch/?trk=cndc-detail) to monitor your databases, queues, and operation portals.\n- **Ownership**. Gain ownership of your EDI and custom or standard rules for rapid change management and partner onboarding.\n#### **Conclusion**\nIn this healthcare use case, we demonstrated how a combination of Amazon Web Services services can be used to increase efficiency and reduce cost. This architecture provides a scalable, reliable, and secure foundation to develop your EDI solution, while using dependent applications. We established how to simplify complex tasks in order to manage and scale your infrastructure for a high volume of data. Finally, the solution provides for monitoring your workflow, services, and alerts.\n#### **For further reading:**\n\n[Serverless Computing using Amazon Web Services](https://aws.amazon.com/serverless/)\n[Serverless and Containers](https://docs.aws.amazon.com/whitepapers/latest/logical-separation/serverless-and-containers.html)\n\n![image.png](https://dev-media.amazoncloud.cn/27be0ffe46df4bf1be2c3f27c5c2d323_image.png)\n\n**Ripunjaya Pattnaik**\nRipunjaya is an Enterprise Solutions Architect at Amazon Web Services. He enjoys problem-solving and advising his customers. In his free time, he likes to try new sports, play ping-pong and watch movies.\n\n![image.png](https://dev-media.amazoncloud.cn/8f91d42495754ddc874a05f13fcb66f6_image.png)\n\n**Prasad Shetty**\nPrasad Shetty is a Boston-based Solutions Architect at Amazon Web Services. He brings more than 20 years of experience in modernizing and delivering Digital Innovation and Transformation projects across enterprises. He is motivated by helping customers architect and optimize applications on Amazon Web Services. In his leisure time, Prasad enjoys biking and traveling.","render":"<p>Electronic data interchange (EDI) is a technology that exchanges information between organizations in a structured digital form based on regulated message formats and standards. EDI has been used in healthcare for decades on the payer side for determination of coverage and benefits verification. There are different standards for exchanging electronic business documents, like <a href=\\"https://www.ansi.org/\\" target=\\"_blank\\"> American National Standards Institute X12 (ANSI)</a>, Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT), and Health Level 7 (HL7).</p>\\n<p>HL7 is the standard to exchange messages between enterprise applications, like a Patient Administration System and a Pathology Laboratory Information. However, HL7 messages are embedded in Health Insurance Portability and Accountability Act (HIPAA) X12 for transactions between enterprises, like hospital and insurance companies.</p>\n<p>HIPAA is a federal law that required the creation of national standards to protect sensitive patient health information from being disclosed without the patient’s consent or knowledge. It also mandates healthcare organizations to follow a standardized mechanism of EDI to submit and process insurance claims.</p>\n<p>In this blog post, we will discuss how you can build a serverless cloud-native EDI implementation on Amazon Web Services using the Edifecs XEngine Server.<a href=\\"https://www.edifecs.com/products/xengine-server\\" target=\\"_blank\\"> Edifecs XEngine Server</a></p>\\n<h4><a id=\\"EDI_implementation_challenges_7\\"></a><strong>EDI implementation challenges</strong></h4>\\n<p>Due to its structured format, EDI facilitates the consistency of business information for all participants in the exchange process. The primary EDI software that is used processes the information and then translates it into a more readable format. This can be imported directly and automatically into your integration systems. Figure 1 shows a high-level transaction for a healthcare EDI process.</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/75406f69bf614bb491c900b0dbaf9e1e_image.png\\" alt=\\"image.png\\" /></p>\n<p>Figure 1. EDI Transaction Sets exchanges between healthcare provider and payer<br />\\nAlong with the implementation itself, the following are some of the common challenges encountered in EDI system development:</p>\n<ol>\\n<li><strong>Scaling.</strong> Despite the standard protocols of EDI, the document types and business rules differ across healthcare providers. You must scale the scope of your EDI judiciously to handle a diverse set of data rules with multiple EDI protocols.</li>\\n<li><strong>Flexibility in EDI integration.</strong> As standards evolve, your EDI system development must reflect those changes.</li>\\n<li><strong>Data volumes and handling bad data.</strong> As the volume of data increases, so does the chance for errors. Your storage plans must adjust as well.</li>\\n<li><strong>Agility.</strong> In healthcare, EDI handles business documents promptly, as real-time document delivery is critical.</li>\\n<li><strong>Compliance</strong>. State Medicaid and Medicare rules and compliance can be difficult to manage. HIPAA compliance and CAQH CORE certifications can be difficult to acquire.</li>\\n</ol>\n<h4><a id=\\"Solution_overview_and_architecture_data_flow_20\\"></a><strong>Solution overview and architecture data flow</strong></h4>\\n<p>Providers and Payers can send requests as enrollment inquiry, certification request, or claim encounter to one another. This architecture uses these as source data requests coming from the Providers and Payers as flat files (.txt and .csv), Active Message Queues, and API calls (submitters).</p>\n<p>The steps for the solution shown in Figure 2 are as follows:<br />\\n<strong>1.</strong> Flat, on-premises files are transferred to [Amazon Simple Storage Service](https://aws.amazon.com/cn/s3/?trk=cndc-detail) (S3) buckets using Amazon Web Services Transfer Family <strong>(2)</strong>.<br />\\n<strong>3.</strong> Amazon Web Services Fargate on Amazon Elastics Container Service ([Amazon ECS](https://aws.amazon.com/cn/ecs/?trk=cndc-detail)) runs Python packages to convert the transactions into JSON messages, then queues it on [Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) <strong>(4)</strong>.<br />\\n<strong>5.</strong> Java Message Service (JMS) Bridge, which runs Apache Camel on Fargate, pulls the messages from the on-premises messaging systems and queues them on [Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) <strong>(6)</strong>.<br />\\n<strong>7.</strong> Fargate also runs programs to call the on-premises API or web services to get the transactions and queues it on [Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) <strong>(8).</strong><br />\\n<strong>9.</strong> [Amazon CloudWatch](https://aws.amazon.com/cn/cloudwatch/?trk=cndc-detail) monitors the queue depth. If queue depth goes beyond a set threshold, CloudWatch sends notifications to the containers through [Amazon Simple Notification Service](https://aws.amazon.com/cn/sns/?trk=cndc-detail) (SNS) <strong>(10).</strong><br />\\n<strong>11.</strong> [Amazon SNS](https://aws.amazon.com/cn/sns/?trk=cndc-detail) triggers Amazon Web Services Lambda, which adds tasks to Fargate <strong>(12),</strong> horizontally scaling it to handle the spike.<br />\\n<strong>13</strong>. Fargate runs Python programs to read the messages on [Amazon MQ](https://aws.amazon.com/cn/amazon-mq/?trk=cndc-detail) and uses PYX12 packages to convert the JSON messages to EDI file formats, depending on the type of transactions.<br />\\n<strong>14.</strong> The container also may queue the EDI requests on different queues, as the solution uses multiple trading partners for these requests.<br />\\n<strong>15.</strong> The solution runs Edifecs XEngine Server on Fargate with Docker image. This polls the messages from the queues previously mentioned and converts them to EDI specification by the trading partners that are registered with Edifecs.<br />\\n<strong>16.</strong> Python module running on Fargate converts the response from the trading partners to JSON.<br />\\n<strong>17.</strong> Fargate sends JSON payload as a POST request using [Amazon API Gateway](https://aws.amazon.com/cn/api-gateway/?trk=cndc-detail), which updates requestors’ backend systems/databases **(12) **that are running microservices on [Amazon ECS](https://aws.amazon.com/cn/ecs/?trk=cndc-detail) <strong>(11)</strong>.<br />\\n<strong>18.</strong> The solution also runs [Elastic Load Balancing](https://aws.amazon.com/cn/elasticloadbalancing/?trk=cndc-detail) to balance the load across the [Amazon ECS](https://aws.amazon.com/cn/ecs/?trk=cndc-detail) cluster to take care of any spikes.<br />\\n<strong>19.</strong> [Amazon ECS](https://aws.amazon.com/cn/ecs/?trk=cndc-detail) runs microservices that uses [Amazon RDS](https://aws.amazon.com/cn/rds/?trk=cndc-detail) <strong>(20)</strong> for domain specific data.</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/fb91062bc25a41cfb75301ac61925e9b_image.png\\" alt=\\"image.png\\" /></p>\n<p>Figure 2. EDI transaction-processing system architecture on Amazon Web Services</p>\n<h4><a id=\\"Handling_PIIPHI_data_41\\"></a><strong>Handling PII/PHI data</strong></h4>\\n<p>The EDI request and response file includes protected health information (PHI)/personal identifiable information (PII) data related to members, claims, and financial transactions. The solution leverages all Amazon Web Services services that are HIPAA eligible and encrypts data at rest and in-transit. The file transfers are through FTP, and the on-premises request/response files are Pretty Good Privacy (PGP) encrypted. The Amazon S3 buckets are secured through bucket access policies and are AES-256 encrypted.</p>\n<p>Amazon ECS tasks that are hosted in Fargate use ephemeral storage that is encrypted with AES-256 encryption, using an encryption key managed by Fargate. User data stored in Amazon MQ is encrypted at rest. Amazon MQ encryption at rest provides enhanced security by encrypting data using encryption keys stored in the Amazon Web Services Key Management Service. All connections between Amazon MQ brokers use Transport Layer Security to provide encryption in transit. All APIs are accessed through API gateways secured through <a href=\\"https://aws.amazon.com/cognito/\\" target=\\"_blank\\"> Amazon Cognito</a>. Only authorized users can access the application.<br />\\nThe architecture provides many benefits to EDI processing:</p>\n<ul>\\n<li><strong>Scalability.</strong> Because the solution is highly scalable, it can speed integration of new partner/provider requirements.</li>\\n<li><strong>Compliance.</strong> Use the architecture to run sensitive, HIPAA-regulated workloads. If you plan to include PHI (as defined by HIPAA) on Amazon Web Services services, first accept the Amazon Web Services Business Associate Addendum (Amazon Web Services BAA). You can review, accept, and check the status of your Amazon Web Services BAA through a self-service portal available in Amazon Web Services Artifact. Any Amazon Web Services service can be used with a healthcare application, but only services covered by the Amazon Web Services BAA can be used to store, process, and transmit protected health information under HIPAA.</li>\\n<li><strong>Cost effective.</strong> Though serverless cost is calculated by usage, with this architecture you save as your traffic grows.</li>\\n<li><strong>Visibility.</strong> Visualize and understand the flow of your EDI processing using [Amazon CloudWatch](https://aws.amazon.com/cn/cloudwatch/?trk=cndc-detail) to monitor your databases, queues, and operation portals.</li>\\n<li><strong>Ownership</strong>. Gain ownership of your EDI and custom or standard rules for rapid change management and partner onboarding.</li>\\n</ul>\n<h4><a id=\\"Conclusion_52\\"></a><strong>Conclusion</strong></h4>\\n<p>In this healthcare use case, we demonstrated how a combination of Amazon Web Services services can be used to increase efficiency and reduce cost. This architecture provides a scalable, reliable, and secure foundation to develop your EDI solution, while using dependent applications. We established how to simplify complex tasks in order to manage and scale your infrastructure for a high volume of data. Finally, the solution provides for monitoring your workflow, services, and alerts.</p>\n<h4><a id=\\"For_further_reading_54\\"></a><strong>For further reading:</strong></h4>\\n<p><a href=\\"https://aws.amazon.com/serverless/\\" target=\\"_blank\\">Serverless Computing using Amazon Web Services</a><br />\\n<a href=\\"https://docs.aws.amazon.com/whitepapers/latest/logical-separation/serverless-and-containers.html\\" target=\\"_blank\\">Serverless and Containers</a></p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/27be0ffe46df4bf1be2c3f27c5c2d323_image.png\\" alt=\\"image.png\\" /></p>\n<p><strong>Ripunjaya Pattnaik</strong><br />\\nRipunjaya is an Enterprise Solutions Architect at Amazon Web Services. He enjoys problem-solving and advising his customers. In his free time, he likes to try new sports, play ping-pong and watch movies.</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/8f91d42495754ddc874a05f13fcb66f6_image.png\\" alt=\\"image.png\\" /></p>\n<p><strong>Prasad Shetty</strong><br />\\nPrasad Shetty is a Boston-based Solutions Architect at Amazon Web Services. He brings more than 20 years of experience in modernizing and delivering Digital Innovation and Transformation projects across enterprises. He is motivated by helping customers architect and optimize applications on Amazon Web Services. In his leisure time, Prasad enjoys biking and traveling.</p>\n"}
目录
亚马逊云科技解决方案 基于行业客户应用场景及技术领域的解决方案
联系亚马逊云科技专家
亚马逊云科技解决方案
基于行业客户应用场景及技术领域的解决方案
联系专家
0
目录
关闭