|
Hello guys,
We are into healthcare application development.
I see there's a good amount of Standardization of the healthcare data. Like HL7 / FHIR etc.
All these are needed for interops between different HC systems.
The question is, Should our App DB schema that will be used internally should also adhere to FHIR standards?
I see these options:
1. Store App Data in application domain schema - just plain JSON with our own attributes. Snappy format helps faster transfers between the Apps.
2. Store App Data in FHIR transformation-compatible format. (Make it easier for ETL later into FHIR std). Schema needs some effort.
3. Sore App Data in full FHIR format. This makes the json payloads heap up like a landslide. A lot of effort upfront and bloated transport all around.
What would you recommend?
modified 30-Sep-23 4:35am.
|
|
|
|
|
If you have a standard, use it.
It means your apps can be more flexible, more generic - and can interface with other manufacturers apps, which is why we have standards in the first place!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Healthcare implementations are complex.
If you notice, Azure FHIR architecture examples never insist we store our Application Data in FHIR standard.
They say just go with what our App needs and don't worry about interop with external systems.
When there's a need for interop, Azure FHIR adaptors can transform the app domain data into standard Healthcaredata.
This has been the recommendation from different corners. But still want to hear from you guys here.
|
|
|
|
|
Apps have a shelf life. One day, someone is going to need to migrate the data in your (presumably) massive vertical healthcare application to some other system.
Use the standard, even if it's a lot of extra work up front. You'll recoup some of it on the back end, because you won't have to do things like document every nook and cranny rather than refer to existing standard docs for your data format.
Gosh just reading your post feeds into my burnout. Ugh, not your fault, it's just, my days of coding monolithic enterprise applications is over.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
This.
Otherwise when it comes to interoperability, you're just creating [standards]+1.
|
|
|
|
|
dandy72 wrote: you're just creating [standards]+1 xkcd: Standards[^]
FTFY
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I was going to link to that, and that is exactly what I had in mind what I wrote my post...
|
|
|
|
|
You store it in the form that normalization dictates; taking into consideration access paths; which means buying off the DBA to forget theory for a minute.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I reject the premise of the question.
|
|
|
|
|
Why ?
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Nand32 wrote: All these are needed for interops between different HC systems....App DB schema
I guess you really mean something like 'data model' rather than 'database' which would be what I see when you say "DB".
Nand32 wrote: What would you recommend?
That requires much more detail about the architecture than what you presented here.
Given that there are different systems then who controls/owns those systems? That is important.
But other than that transforming data between systems on communication pipelines is always a given. Even if was a good idea to use the same standard for all each system must still serialize/deserialize the binary into data. So the transform layer will always exists.
And it depends on the systems on the pipe. It would seem really unlikely that you could create one template/definition to which every single system must conform when those systems must in fact be each doing something different. Not without adding unneeded complexity.
What happens if you provide one standard to which 100 systems must adhere and yet a change is needed so just 2 of those systems can be updated?
So ignoring all of that, if the existing external models can be easily broken down (important) to sub-models which mostly meet the communication needs of two systems, then you can use that between those two systems. But I suspect you will still need an envelope into which the sub-model is passed.
|
|
|
|
|
Wordle 833 5/6
🟨⬛⬛⬛⬛
⬛⬛🟨⬛⬛
🟩🟩⬛⬛🟩
🟩🟩⬛⬛🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 833 5/6
⬛⬛🟨⬛⬛
🟨⬛🟩⬛⬛
⬛🟩🟩⬛⬛
⬛🟩🟩🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 833 3/6
🟨🟨⬜⬜⬜
⬜⬜⬜🟨🟨
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 833 4/6
⬛⬛🟨⬛⬛
⬛⬛🟩🟨🟩
⬛🟩🟩⬛🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 833 6/6*
🟨⬜⬜⬜⬜
⬜⬜⬜🟨🟩
⬜🟩⬜⬜🟩
⬜🟩⬜🟩🟩
⬜🟩⬜🟩🟩
🟩🟩🟩🟩🟩
So nearly broke my streak!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
⬜⬜🟨⬜⬜
⬜⬜⬜⬜⬜
🟨⬜⬜⬜🟩
⬜🟩⬜⬜🟩
⬜🟩⬜⬜🟩
🟩🟩🟩🟩🟩
Thought I'd lost
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 833 4/6
🟨🟨⬛⬛⬛
🟩🟩⬛⬛🟩
🟩🟩⬛🟩🟩
🟩🟩🟩🟩🟩
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 833 6/6
⬜⬜⬜⬜⬜
⬜⬜⬜🟨⬜
🟨🟨⬜⬜⬜
🟩🟩⬜⬜🟩
🟩🟩⬜⬜🟩
🟩🟩🟩🟩🟩
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I'm contractor for one of the wealthiest companies in the country. They have enough money to buy best in class software from biggest names in the industry.
2 out of 3 internal departments ( Eng. and Utility departments ) that I've worked with, know me and trust in my software. Now I'm going to introduce myself to the 3rd and most important department ( Maintenance Dep. ). Generally speaking, Management and engineers in this department go for the big names and don't waste their time and money on unknown vendors.
I'm brave enough to host them in a meeting in coming months. I'm thinking about the ways I can assure them about my software. Management and Engineers from the first 2 departments have told me, If they are asked, will talk in favor of me. Literally, this is the only chance I have.
Please share your thoughts, hints and suggestions for the meeting.
Edit: The software I'm talking about is a critical mission software used in Oil Industry. Big players claim 7 nines Availability. My software is good ( enough?? ) in this regard ( 5 nines). TBH, It's a very fierce and tough competition.
Thanks
Behzad
modified 2-Oct-23 14:31pm.
|
|
|
|
|
...ok so u sold to two dept and want the third dept to buy... possibly they should do a pilot and evaluate and come to a decision and then
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Behzad Sedighzadeh wrote: Management and Engineers from the first 2 departments have told me, If they are asked, will talk in favor of me.
Having departments A and B vouch for you is your best chance, IMO, to get your foot in the door and cut through corporate red tape. Department C knows you're known and trusted by someone else internally. You can't ask for a better position to be in.
All I can add is, good luck.
|
|
|
|
|
In an ideal world you could just present something and they would be able to see what you can do from that.
But it isn't ideal. So politics are better.
Call the two depts that know you A/B.
And the one that doesn't C.
What you want is the following
1. Someone in A/B that is known to be technically proficient by someone of significance in C.
2. Someone in A/B that is known as an excellent manager by someone of significance in C.
Then you have that person talk to the person in C.
Of course better if you have more than one person that can do this.
Also you would want to make sure that the person (or persons) does not have any 'issues' with someone else in C. Doesn't matter if they have a good rep with one person in C but also has a bad rep with someone else. That second person would then end up fighting against without even knowing anything about you.
What does 'significance' mean?
1. A senior level engineer who is respected.
2. A manager at the tech level who is respected. You don't want something like a VP because then the tech side will probably look down upon the reference. But then the might force the decision and you could prove yourself over time.
3. Even to some extent someone that is just popular.
|
|
|
|
|
Behzad Sedighzadeh wrote: Please share your thoughts, hints and suggestions for the meeting.
You ever notice that the more expensive a product is, the less you see the price on the site? It's always call us. It'll be business speak because the business doesn't care about or even understand the tech speak -- and then contact us for sales.
Ever wonder why that is?
It's because the business side doesn't give two flips about the tech. What they care about is reliability, the cost, and what happens if something goes wrong. That's probably why they prefer big name vendors, you can trust they are reliable. A no name has no guarantee of quality or assurance. They never will.
For instance, open source software is free and pretty good tech. Business doesn't care at all. Not unless they save millions and can hire someone to deal with it. For average stuff, they won't care two flips. They have the money; what they need is a solution they can trust.
Which is to say, when you're going into sell this thing. Yes, talk about the software. But remember, you're selling YOU... not the software. If they trust you and/or your team you have a chance. If they don't, nothing you say about the software will make a difference - ever.
Also, don't get cheesy when you're selling yourself. Just be genuinely friendly. Don't try and sell them. Just be their friend and honest. If there's a shortcoming with your offer SAY IT. It'll come out in the wash anyway. But, earn their trust.
By now the word trust should be evident. 
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: You ever notice that the more expensive a product is, the less you see the price on the site? It's always call us
We used to have a salesguy who answered quotes requests with, "what's your budget?"
And he wasn't necessarily wrong in asking that. Primarily, he preferred to have people call before giving out a price so he could discuss and understand their exact situation, identify their needs, whether our software/services were a good fit, and find opportunities for custom work.
The way he saw it, the majority of potential customers who just look at a figure on a web site and turned back without engaging were not going to be a good deal anyway.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
