Я работаю над интеграцией PhilHealth (Филиппинская корпорация медицинского страхования) в существующую систему управления больницей, построенную на основе ASP.NET Core (.NET), Entity Framework Core и SQL Server.
На данном этапе:
У нас еще нет доступа к официальной API-интерфейсы PhilHealth, WSDL или конечные точки песочницы
У нас нет окончательных XML-схем
Все еще необходимо начать архитектурные и проектные работы на основе общедоступных рекомендаций PhilHealth (CF1, CF2, приемлемость и рабочий процесс претензий)
В чем я не уверен
Рекомендуемая общая архитектура, когда официальные API SOAP еще недоступны
Как правильно разделить обязанности между:
доменными службами и репозиториями
Сборщики/сериализаторы XML против бизнес-логики
Как спроектировать систему, чтобы она могла в дальнейшем поддерживать:
Конечные точки SOAP
Взаимную аутентификацию TLS/сертификат
Отдельные среды тестирования и производства
Реальная обработка:
Правомочность → подача заявки → жизненный цикл статуса заявки
Стратегии повторной отправки, повторной подачи и сверки
Журнал аудита и соблюдения требований
Распространенные ошибки, которых следует избегать при раннем начале интеграции PhilHealth (или аналогичной государственной страховки)
Чего я не прошу
Учетные данные PhilHealth
Собственные WSDL или внутренняя документация
Полные рабочие реализации
Что мне нужно
Общее руководство по архитектуре
Шаблоны проектирования, подходящие для интеграции SOAP/XML в здравоохранении
Уроки, извлеченные из аналогичных систем государственного страхования
Советы по готовности дизайна к будущему перед официальным внедрением
Любые рекомендации от разработчиков, которые работали над Мы будем очень признательны за PhilHealth, интеграцию государственного страхования или аналогичные системы здравоохранения SOAP/XML.
Я работаю над интеграцией [b]PhilHealth (Филиппинская корпорация медицинского страхования)[/b] в существующую [b]систему управления больницей[/b], построенную на основе [b]ASP.NET Core (.NET), Entity Framework Core и SQL Server[/b]. На данном этапе: [list] [*]У нас [b]еще нет доступа[/b] к официальной API-интерфейсы PhilHealth, WSDL или конечные точки песочницы
[*]У нас [b]нет окончательных XML-схем[/b]
[*]Все еще необходимо начать архитектурные и проектные работы на основе [b]общедоступных рекомендаций PhilHealth[/b] (CF1, CF2, приемлемость и рабочий процесс претензий)
[/list] В чем я не уверен [list] [*]Рекомендуемая [b]общая архитектура[/b], когда официальные API SOAP еще недоступны
[*]Как правильно разделить обязанности между: [list] доменными службами и репозиториями
[*]Сборщики/сериализаторы XML против бизнес-логики
[/list]
[*]Как спроектировать систему, чтобы она могла в дальнейшем поддерживать: [list] Конечные точки SOAP
[*]Взаимную аутентификацию TLS/сертификат
[*]Отдельные среды тестирования и производства
[/list]
[*]Реальная обработка: [list] Правомочность → подача заявки → жизненный цикл статуса заявки
[*]Стратегии повторной отправки, повторной подачи и сверки
[*]Журнал аудита и соблюдения требований
[/list]
[*]Распространенные [b]ошибки, которых следует избегать[/b] при раннем начале интеграции PhilHealth (или аналогичной государственной страховки)
[/list] Чего я [b]не[/b] прошу [list] [*]Учетные данные PhilHealth
[*]Собственные WSDL или внутренняя документация
[*]Полные рабочие реализации
[/list] Что мне нужно [list] [*]Общее руководство по архитектуре
[*]Шаблоны проектирования, подходящие для интеграции SOAP/XML в здравоохранении
[*]Уроки, извлеченные из аналогичных систем государственного страхования
[*]Советы по [b]готовности дизайна к будущему[/b] перед официальным внедрением
[/list] Любые рекомендации от разработчиков, которые работали над Мы будем очень признательны за [b]PhilHealth[/b], [b]интеграцию государственного страхования[/b] или аналогичные [b]системы здравоохранения SOAP/XML[/b].
Мобильная версия