I already have a UI made but I want to add :
-
Adhaar Card No.
-
Name
-
Mobile No.
Fields to the form.
How do I reflect the same on the backend
Hi,
These are generally part of the patient demographics in EHR systems. You can use some available solution or create your own for that purpose.
regards
Thank You Sir for responding
I am trying to make a demographics archetype but I am confused as to what RM type should be assigned to it
Pablo’s advice is good but it does require a dedicated demographics repository, and I’m not sure there is such a thing freely available. I tend to recommend looking at a simple FHIR demographics server for small-scale needs
As has already been said, you really, really should not be putting person demographic details in the CDR… however … if for whatever reason you did have to build a person archetype, an ADMIN_ENTRY is the correct start point. So by all means do this for your own learning but walk away quickly and investigate storing the person’s details in a separate service .
2 Likes
Thank You @ian.mcnicoll @pablo
I cannot understand one thing which is why do we need a seperate server for demographics , can’t I just use the EHRbase server in which i have posted my template before OR Is that also possible ?
Hi Yash,
this is a simple view of what a minimum platform might look like.
EhrBase itself is an implementation of the EHR repository (also often called a CDR or Clinical Data Repository). The demographic repo is on the right. This is a logical picture; normally these two and also any other local services are all running on the same DB product, i.e. Oracle, Postgres, Mongo or whatever. In RDBMS terms, EHRs and Demographics (PARTY and related entities) are represented in different top-level table structures.
You can see a somewhat more sophisticated platform concept here in the Catalan RFI:
This is more or less the same thing, with the Demographics repository represented as an optional demographics cache (follows the openEHR demographic model) and an external MPI (here FHIR, but you are probably using something different). The demographics cache adds versioning and allows archetyping.
A 3rd architecture is to just use references to the external PMI from within the EHRs. In this case you have no control over the demograhics info representation, but that may be fine (often it is).
The ‘EHR subject index’ shown in the above diagram is a x-ref DB relating EHR ids to Subject (i.e. patient) ids, for more secure systems. In such a system, if all the data are stolen apart from this table (which should be on a high security separate physical infrastructure), the patient identities won’t be known from the EHRs (well, there are ways to guess, but that’s another topic).
2 Likes
Thank You , I understand everything much better now
1 Like