Contratos de API
O que precisa ser documentado para transformar as alternativas em um catálogo executável.
Inventário de operações a solicitar
Cada linha abaixo representa uma necessidade funcional proposta, não o nome de um endpoint existente. A equipe Tasy deve devolver a operação real ou registrar formalmente a indisponibilidade.
| Domínio | Operações necessárias no piloto | Pontos do contrato |
|---|---|---|
| Unidades | Listar estabelecimentos e alterações. | Código estável, hierarquia, nome, situação e escopo por empresa. |
| Profissionais | Listar profissionais e vínculos com unidade/especialidade. | Identificador, conselho/UF, status, vigência e múltiplos vínculos. |
| Especialidades e serviços | Listar classificações e procedimentos. | Código de origem, descrição, equivalências e inativação. |
| Convênios e planos | Listar produtos e vínculos de atendimento. | Operadora, plano, unidade, cobertura, exclusões e validade. |
| Preços | Consultar valores aplicáveis por contexto. | Procedimento, tabela, unidade, plano, vigência, moeda e regras de negociação. |
| Agendas | Consultar recursos, períodos e disponibilidade, se autorizados. | Fuso, bloqueios, intervalo, frescor e regras de reserva. |
| Mudanças | Consultar alterações, exclusões lógicas ou eventos. | Cursor, ordenação, janela histórica, reprocessamento e limites. |
Ficha obrigatória de cada operação
- Identificação: produto, versão, módulo, responsável, status de suporte e data da especificação.
- Endereços separados de homologação e produção, método/operação e versão do contrato.
- Autenticação efetiva: conta técnica, token, certificado ou outra modalidade documentada. OAuth não deve ser presumido.
- Permissões por recurso, empresa e estabelecimento; prazo e processo de renovação.
- Campos obrigatórios, identificadores, códigos de situação, datas, nulos, precisão e exemplos sintéticos.
- Filtros suportados, paginação, ordenação estável, máximo de itens e limites de requisição.
- Códigos de erro, timeout, indisponibilidade, idempotência e comportamento de atualização concorrente.
- Política de mudança, descontinuação, comunicação de incidentes e canal de suporte.
Se o fornecedor oferecer FHIR
Solicitar a URL base e o CapabilityStatement correspondente ao servidor. O padrão define a consulta de capacidades em [base]/metadata. Conferir versão FHIR, recursos, perfis, interações, filtros e mecanismos de segurança declarados antes de desenvolver.
- HL7 · FHIR R4 RESTful APIContrato do padrão FHIR R4; não comprova que o ambiente Tasy possua esse serviço.
- HL7 · CapabilityStatement R4Como declarar e verificar capacidades de um servidor FHIR.
| Informação de negócio | Recurso FHIR candidato · validar cobertura |
|---|---|
| Profissional e vínculo | Practitioner / PractitionerRole |
| Unidade e local | Organization / Location |
| Serviço oferecido | HealthcareService |
| Agenda e horário | Schedule / Slot |
| Compromisso agendado | Appointment · somente se esse escopo for aprovado |
| Paciente / atendimento / laudo | Patient / Encounter / DiagnosticReport · fora do piloto |
Este é um mapeamento conceitual, não uma lista de APIs Tasy disponíveis. Especialidade, preço comercial e regras de convênio podem exigir códigos, extensões ou contratos próprios; não possuem equivalência automática com um único recurso.
- HL7 · Catálogo de recursos FHIR R4Vocabulário de recursos utilizado no mapeamento conceitual proposto.