Electronic health record that is exposed to FHIR server - hl7-fhir

Can anyone tell me any real Electronic health record that is present on FHIR server? I want to predict hospital readmission on such data.

There is real data available from numerous EHRs, but you will only be able to access the data if you are a patient (in which case you can only access your own data), you're a provider with organization whose data is managed by the EHR (in which case you'll only have access to data you have a right to see as a provider), or you have a data sharing arrangement with the organization - which will typically mean you'll get access to a de-identified clone of the production data.

Related

Central list of SMART on FHIR endpoints

I am building a SMART on FHIR app for patient mediated EHR analysis.
Is there a centralized list of SMART on FHIR endpoints? For example, Epic provides this list of endpoints, and a very nice patient facing website to access Epic MyChart for a particular clinic. It is searchable by location. So I can search for "Maryland" and see all clinics with MyChart for that state.
I seek to replicate the Epic MyChart access page, but add SMART on FHIR endpoints from eClinicalWorks, Cerner, and other vendors. I think a central and continually updated list of SMART on FHIR endpoints would be beneficial to EHR interoperability - especially if it were open source and updated frequently. The information is all public, it would be a matter of compiling it and keeping it updated. Is there such a list that already exists?
Right now we are working on a specification to provide more consistent publication of endpoint and branding information to help patients select their provider. We are aiming to have each vendor openly publish more complete data in a consistent format. From there, compiling a centralized list should be possible.
Feel free to check out https://hackmd.io/#argonaut/patient-access-brands for details.
Probably not quite what you're after, but I wanted to point out that Lantern aggregates published FHIR API endpoints and some details about them.

One database per API or shared database for multiple APIs in Microservice

I started reading microservices architecture and got confused with one below point.
Each service should have a separate database.
Does each service mean a single web(rest) api having its own database?
For example if I take motor insurance claim operation as a business scenario where I modelled business domain services in 3 part Insurance claim services , partner (automobile service providers) services and customer services.
Insurance claim settlement operation in claim api will require other information like incident , survey done by an inspector, policy detail , documents etc.
Now I can create 5 web(rest) api in Insurance claim services and will store its data in common db and other services like partner and customer service will have their own web apis and db
What is correct ?
All web api (claimAPI, PolicyAPI, IncidentAPI, SurveyAPI and DocumentAPI) in claim insurance services should have their own db or they can keep data in single data base ?
Thanks.
To follow microservice best practice, it is correct that they should each have their own database and be exposed solely by APIs. This is because every service in your architecture should be independent and de-coupled from other services. If 2+ services share a database, then there may arise problems in operation or upgrade.
One big issue with a shared database is each service would need to trust that another service doesn't modify it's information. But since they all have access to the same database, one of the others could in fact modify the underlying data and make things unstable or insecure.
Further, with 2+ services relying on a shared database, then you're forced to use the exact same database/version with all. You lose the freedom to independently use MySQL for one and MongoDB for another. Even if the same tool is used for all, when you do maintenance or migration on one you're forced to do it for the rest. All this adds up to some coupled services that make them harder to maintain and scale.
you can have common database for all microservices, it is one of the microservices patterns:
https://microservices.io/patterns/data/shared-database.html
https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/shared-database.html
check those links to see advantages and disadvantages of this approach.

Microservice Data Duplication vs Single Responsibility

I am new to microservices and trying to break up a big monolithic application into microservices. While scoping the microservice I am unable to decide whether I should go for a data duplication between services or ignore SRP by clubbing all requiring the same data into 1 service. Following is the scenario.
I have a service which receives Customer order say build a car with these parts and features. Now I have other 2 functionalities which uses the Parts and features to derive some runtime value say ;
If the order contains part A and Feature A then perform X operation. As each of these functionalities have there respective UI for configuration and runtime engine to derive the output and most of the time changes only comes in these respective function blocks, I thought of creating the separate microservices.
Creating the separate microservice would need data(Parts and Features) to be duplicated. Another option could be given each of these service uses the same data is clubbing all of them into 1, but with that I again create a big service which if goes down will stop all 3 functionalities and is against SRP. Another option could be when the data is required by the other 2 services make a call and get it from Order Service, but that is making it highly dependent and getting the data over network for each operation.
Can anyone suggest what would be ideal to do in such case.
Microservice should communicate via events using publisher/subscriber model and topics. See the tri-lateral design pattern. In a pub/sub system the producer writes the event to the topic and a broker makes it available to each subscriber, aka microservice. This is one advantage of eventing, one producer, and many consumers.
Order A has a BOM that expresses parts and features an order represents. When the order is placed, other services need that information such as the feature/part microservice and UI components and their respective datastores. For example, define two topics parts-ordered and features-ordered.
The order microservice writes to the parts and features topics respectively. The feature, parts, and UX microservices read and act upon those events.
You need to make a choice about your system of record. You can write to an orders DB before publishing the events, or let the pub/sub it. In your example, it sounds like you are talking about three different tables; order, parts, and events. That decomposes cleaning into the microservices you describe where each maintains the data it is responsible for. I'd be inclined to just use the pub/sub as your audit trail.
If you are writing in Go we have blueprints for the most common design patterns.
First, you mentioned that you are trying to convert the monolithic application into microservices. You can create/caters the microservices on basis of domain data, we can be called it domain-driven architecture.
Suppose you have the business functionality for customer data, customer order, customer order handling, and customer payment. And currently, it's part of a monolithic application. So you can create the subdomain for each functionality like Customer domain, Order domain, order handle domain, and payment domain respectively. Each domain contains several microservices depends on the business requirement.
For e.g you can check the Amazon website, In personal/customer data, you see the customer name, phone number, address, billing account information, delivery address type(office/home). In this case the under customer domain, there will be 3 microservices required(It totally depends on your domain design). One for customer(handles customer name, phone number, reference of Billing account id, reference of address id), second for Billing account(Billing account number, billing account information, reference if customer id), third for Address data(customer office address, preferable address). And for each microservice, there will be a dedicated database/buckets, Only that microservice can change/add the data. If any other microservice wants to add/update/get data, it needs to be get by calling that microservices HTTP endpoint over the network.
Updating the data in other microservice::
Now coming to your question about data duplication, Let's consider the above example.
If Customer microservice wants to store/ cache the billing account data for some purpose, that microservice can store that data in the database but again Customer microservice needs to make sure that, the current data of the billing account is always real one and not the old one. For this customer, microservice needs to listen to the event whenever there is update in billing account data, so old data in billing account gets purged and customer microservice always has the latest data of billing.
you can read here about event driven architecture.
https://en.wikipedia.org/wiki/Event-driven_architecture#:~:text=Event%2Ddriven%20architecture%20(EDA),sale%22%20to%20%22sold%22.
You can read more about this at the below links about Domain driven design.
https://www.thoughtworks.com/insights/blog/domain-driven-design-services-architecture
https://en.wikipedia.org/wiki/Domain-driven_design
This is my free book :)
https://github.com/vaquarkhan/microservices-recipes-a-free-gitbook
If you want to create microservice then need to follow microservice guideline.
Now come to real world :) really difficult to meet all microservice requirements as database has own licensing cost etc. so you can choose pragmatic microservices. You can get started with them faster and pick and choose the pieces that make sense for your team.
Design Domain driven design oriented microservice : DDD talks about problems as domains. It describes independent problem areas as Bounded Contexts and each Bounded Context correlates to a microservice.
Where to draw the boundaries is the key task when designing and defining a microservice.
DDD patterns help you understand the complexity in the domain, the domain model for each Bounded Context, you identify and define the entities, value objects, and aggregates that model your domain. You build and refine a domain model that is contained within a boundary that defines your context. And that is explicit in the form of a microservice. The components within those boundaries end up being your microservices.
https://martinfowler.com/bliki/AnemicDomainModel.html
https://github.com/vaquarkhan/Domain-driven-design
https://github.com/vaquarkhan/ddd-by-examples.github.io/blob/master/ddd-factory.pdf
Now you can create layers on top of you microservice and build complex logic using orchestration and choreography.
Example :
Gateway  Customer order Application layer microservice --domain model layer microservice  infrastructure layer
There are various ways to decompose an application into services.
1.Decompose by business capability
2.Decompose by subdomain
And there are various ways for data management also
SAGA
API Composition
Database per service
Please go through with the link for more details click

Google Client Library for Java SDK and GDPR

I am using the Google Client Library for Java SDK in my Android app to interface with Google Drive.
Do Google act as a Data Controller or Data Processor by using this SDK? I need to know if I need to store any data to show the user has consented to my app interfacing with Google Drive in line with GDPR.
I know I need to ask permission for personalised or non-personalised ads but the Google Drive SDK and GDPR stuff is driving me crazy.
Thanks
Disclaimer I am not a legal type person this is my opinion from the guidelines that we have been given. You should also seek independent legal advice relating to your status and obligations under the GDPR, as only a lawyer can provide you with legal advice specifcally tailored to your situation.
For refrence I am going to quote from the following documents which as of my writing are the only thing Google has released with regard to GDPR that i am aware of ath this time
Google Cloud & the General Data Protection Regulation
GOOGLE CLOUD & THE GDPR WHITEPAPER
Google Cloud & the General Data Protection Regulation (GDPR)
G Suite1
and Google Cloud Platform customers will typically act as
the data controller for any personal data they provide to Google in
connection with their use of Google’s services. The data controller
determines the purposes and means of processing personal data,
while the data processor processes data on behalf of the data
controller. Google is a data processor and processes personal data
on behalf of the data controller when the controller is using G Suite
or Google Cloud Platform.
Data controllers are responsible for implementing appropriate
technical and organisational measures to ensure and demonstrate
that any data processing is performed in compliance with the GDPR.
Controllers’ obligations relate to principles such as lawfulness,
fairness and transparency, purpose limitation, data minimisation,
and accuracy, as well as fulfilling data subjects’ rights with respect
to their data.
If you are a data controller, you may find guidance related to your
responsibilities under GDPR by regularly checking the website of
your national or lead data protection authority under the GDPR (as
applicable)2, as well as by reviewing publications by data privacy
associations such as the International Association of Privacy
Professionals (IAPP).
You should also seek independent legal advice relating to your status
and obligations under the GDPR, as only a lawyer can provide you with
legal advice specifcally tailored to your situation. Please bear in mind
that nothing on this website is intended to provide you with, or should
be used as a substitute for legal advice.
Gsuite is Googles sweet of tools that being Drive, Calendar ... they are the data controller for the data behind the Google tools.
Controller vs. Processor
(7) ‘controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law;
(8) ‘processor’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller;
IMO
If you are accessing a users data on Google Drive and changing it or doing anything with it then yes you are going to need to tell them what you are using their data for and log their consent. If you are saving their data anywhere then you are also going to have to give them the ability to delete that data.
There are some things you cant do for example if they want to delete all their files on drive thats not your responsibility that's Googles. You are only responsible for the data thats on your system and what you have done with it.
Using googles client library IMO doesn't have much to do with GDPR its what you are doing with the data that they return that matters. I did contact google a few months ago hoping to get some official guidelines with regard to GDPR and the client libraries. I have not heard anything as of yet.

tracking all consumers for WEB API

I have standard enterprise level WEB Api , which is going to be used across the organisation. I can have demarcation like Mainframe Systems/Online channel/etc through API key.
However there can be many systems( say many systems in online) in WEBAPI that can share the same key. I need to identify each and every call uniquely and if it is not being shared
any ways for it?
You could just log the IP address of each request. If all the systems are internal to your organisation then it shouldn't be hard to match IPs to what system it is.
Edit
Or you could pass a client Id as well as the API Key.

Resources