Access Based Media Manager (5 Viewers)

So this is an application that the healthcare patients use - they supply the docs (through scanning, attaching), and review and then may send those to a medical record - is that external? If so the process for accepting such records may/will need stringent verification/validation, which may affect the data needed in your application.
Re the schema - this appears to be a simple star schema - optimal for reporting purposes, however, given the input side of the coin, there is no facility indicated/ needed (as far as data is concerned) to manage the patient details beyond the most basic, like who is doing the scanning (user management)?
Reflecting on the combining the dimensional data into a single table - yes - however, do you envisage any dimensions that change - slowly changing dimensions, in reporting databases, support date ranges in which values are valid - this may not apply to your proposal. I would be very surprised if all the dimensions a single attributes - but I may not be understanding what you want. eg Provider - is this simply the name of the Dr. What role does the Dr have - the referring Dr, the specialist? What is Patientclass?, Can a document belong to multiple types? eg An x-ray, and raw/png/jpeg ... and can documents be related to each other - eg the x-ray image is linked to the report by the cardiologist?
Also depending on how you expect/envisage users being able to add additional classification values, if you simply follow @MarkK 's suggestion, then you either lose control of the allowable values (users type in values they use - and then standardisation is lost) or the list is not updateable (except by allowing users to add to the list of accepted values themselves in design view - leading to the same loss of standardisation), however I'm sure you are across those issues.
This is a tool for patients to organize all their medical records so they can easily gather and supply relevant records to providers who request them upon demand. Providers are organizations within the same network, such as affiliated clinics and hospitals that use the same EHR (Electronic Health Records) system. Departments are medical specialties, like Cardiology, Primary Care, and Attending are the clinicians, such as Doctors, Nurses, Techs. This tool is most useful when providers don't have access to relevant records because they originate from outside the providers network. Example: Providers who use Cerner EHR cannot access records stored in Epic, AthenaHealth, and other EHR systems because there's no interoperability between these EHR's, or the provider network restricted access to only within their organization. In the past, providers requested records from outside providers via fax, but now they're asking patients to supply them for upcoming visits, or upon demand.

I am almost done developing and testing the tool, and will soon post some screenshots,
 
Last edited:
Cerner EHR cannot access records stored in Epic, AthenaHealth, and other EHR systems because there's no interoperability between these EHR's, or the provider network restricted access to only within their organization.
Yes, the sensitivities of personal health information (and consequent regulation), as well as the breadth and depth of health data makes interoperability extremely complex. While your application is simply to provide a (set) of health documents, they remain outside the commercial EHR application. HL7 is a widely used protocol that is employed to support exchange of data in health apps (however usually only within the bounds of the defined organisation). IIRC there has been work done within HL7 to define the exchange of structured medical docs (like hosptial discharge summaries). A genuine EHR scope extends beyond the bounds of a commercial app implemented within an organisation - it has to be able to support (capture, store (or point to) and present) the full set of health events over the lifespan of the individual - no matter what, where or when those health events occurred.
 

Users who are viewing this thread

Back
Top Bottom