Interoperability Support at BCBSKS

BCBSKS offers the following guidance to developers.

BCBSKS recommends reviewing the United States Government Regulations and Guidance (aka CMS)
https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index 

The CMS regulations include policies, which require payers to implement APIs to improve the electronic exchange of health care data – sharing information with patients or exchanging information between a payer and provider or between two payers. APIs can connect to mobile apps or to a provider electronic health record (EHR) or practice management system to enable a more seamless method of exchanging information.

For patient access API, SMART on FHIR API, provider directory API documentation, please reference the APIs link above.  

Privacy and Safeguarding Personal Information

Ensuring the privacy and security of patient information is a top priority for BCBSKS. BCBSKS utilizes the CARIN Alliance code of conduct as a guide to provide consumers with transparency into how their information is being used and disclosed.
https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/

BCBSKS is required by law to maintain the privacy of PHI, in accordance with the HIPAA Privacy Regulations.

BCBSKS gathers developer details to provide patients opportunities and information to protect patient data and make informed decisions about sharing patient health information with third parties. For instance, as part of the CMS rule, BCBSKS may ask third-party application developers to attest to privacy provisions, such as whether their privacy policy specifies secondary data uses and inform patients about those attestations. BCBSKS is partnering with developers to provide patient education about sharing their health information with third parties.

Getting Started

1.     Create an account here at the BCBSKS developer portal.

2.     Explore the available APIs.

3.     Exchange email communication with BCBSKS Application Security team to complete the developer questionnaire.

       ·       BCBSKS Application Security team will initiate the email sent after the account is created in step #1.

       ·       During this email exchange developers are required to agree to BCBSKS’s legal terms of service.

4.     Maintain healthy interactions with BCBSKS APIs to avoid disruption of your service.

BCBSKS staffs a 24/7 security incident response team that will react to perceived malicious attacks against BCBSKS APIs. BCBSKS must ensure security of our environment and will take appropriate actions to disrupt malicious attacks. If a developer's API interactions are identified as the source of a malicious attack, BCBSKS will flag the developer subscriptions as “at risk.” See the “at risk” section at the bottom of this web page for additional information.

BCBSKS maintains an internal Computer Incident Response Team (CIRT) policy and will follow the CIRT event procedures for malicious attacks against BCBSKS Interoperability APIs.

Authentication and Authorization

BCBSKS utilizes SMART on FHIR guidance for authentication and authorization. SMART on FHIR relies on OAuth 2.0 OpenID Connect.
http://www.hl7.org/fhir/smart-app-launch/
https://smarthealthit.org/

At this time, BCBSKS is unable to provide dynamic client registration. Instead, this step is conducted manually via the above step #3.

The provider directory APIs are unique because they do not require a subscription. The provider directory APIs are open because they provide publicly available content. BCBSKS provider directory endpoint URL - https://api.secure.bcbsks.com/bcbsks/fhir-prov-dir/api/v4

Provider directory methods include: HealthcareService, InsurancePlan, Location, Organization, OrganizationAffiliation, Practitioner, PractitionerRole

Additional public content is hosted for SMART on FHIR services. These services provide public content documenting the BCBSKS APIs.
Production:
https://api.secure.bcbsks.com/smart-fhir/api/metadata
https://api.secure.bcbsks.com/smart-fhir/api/.well-known/smart-configuration
Sandbox:
https://api.secure.bcbsks.com/smart-fhir-sandbox/api/metadata
https://api.secure.bcbsks.com/smart-fhir-sandbox/api/.well-known/smart-configuration

At Risk

Developer subscriptions become flagged as “at risk” via three methods: malicious activity, inactivity, and significant security breach for their organization.

If a developer's API interactions are identified as the source of a malicious attack, BCBSKS will flag the developer subscriptions as “at risk.” BCBSKS may initiate an internal CIRT event in these situations. A few examples of malicious activity include: brute force attacks, password guessing, password cracking, password spraying, and/or credential stuffing.

Additionally, BCBSKS will flag inactive developer subscriptions. Developer subscriptions are at risk of being discovered inactive after two months of inactivity. BCBSKS authentication services and API endpoints are referenced for indications of activity. BCBSKS will then email the involved developer. If no response is sent by the developer within two weeks, BCBSKS will email the same contact a second time. If no response is sent by the developer within a month, BCBSKS will change whom they are attempting to email, contacting other staff at the same organization. If another week goes by with no response, BCBSKS will remove all accounts and the organization will need to restart their BCBSKS API interactions by revisiting step #1 above.

Lastly, BCBSKS will flag developer subscriptions as “at risk” due to significant security breach for their organization. BCBSKS utilizes RiskRecon for active risk monitoring and alerting. If RiskRecon alerts BCBSKS to security concerns, BCBSKS utilizes RiskRecon’s collaboration invite. This process emails the developer offering access to RiskRecon’s platform to review the details they captured.

Additional Insight Into BCBSKS Security Risk Evaluations

BCBSKS requires securing data both in transit and at rest:

•           Ensure all communications are secured, e.g. HTTPS, TLS, etc.

•           Utilize secure means of data storage for all app data.

•           BCBSKS does not allow unsecure persistent authentication locally stored. OWASP states, “Persistent authentication (Remember Me) functionality implemented within mobile applications should never store authentication details on the device.”

BCBSKS encourages OWASP best practices.
https://owasp.org/www-project-top-ten/
https://owasp.org/www-project-mobile-top-10/

BCBSKS will initiate internal CIRT process(es) when malicious activity is identified.

BCBSKS will effectively protect all resources at BCBSKS with the goal of securing members' data.