gdadlaney / dhde Goto Github PK

Complete the app.get(:mrn) function in hie.js -

• Check the directory for the file. Use the fs.readdirSync() method(Actually done using statSync()).
• If the file with given MRN does not exist, return a 404.
• Add some code for user input. You ask the user to choose between 2 choices, 1) Upload a file or 2) Request a file.

Qs about CCDAs -

1. Can they be appended/concatenated?
2. What name can we give to each file?
3. Are they a universal format?

Others -

1. Find a genuine CCDA, upload it to the drive folder.
2. Find the significance of MRN. We probably cannot use it as the file name(+TimeStamp).

Development -

1. Extract values from the CCDA.
2. Integrate with existing backend.

Refer the MOM in the notes doc for more info

Need to generate an object which will contain the final block data. preprocess() is called after a POST request for file upload has been completed. The data from preprocess() will be sent to the blockchain communicator.

block_data = {pat_id: '12', mrn:'23', ehr_id: '45', doc_id: '56'}
Functions to be implemented -

• function fileHash(file_name, dir_path) returns hash.
• function preprocess(metadata, dir_path) returns block_data object.
  • Create global id by concatinating ehr_id & pat_id
  • Find a method to generate timestamp in node
    Note: preprocess() calls fileHash() internally.
    Note: file_name is mrn+".xml"

Contents of metadata object

1. Patient Id
2. MRN
3. Hash
4. EHR/HIE Id (temp: stored in .env file at ehr side)
5. doctor Id
6. Timestamp

block_data = {pat_id: '4512', mrn:'23', hash:34, ehr_id: '45', doc_id: '56', timestamp: 78}

Use better variable names, if you can think of any

The demo will go like this:

1. A doctor uploads a ccda using the uploadCCDA UI. The doctorId, name and a treatment_complete flag need to be logged onto the blockchain as well. (Add the 3 fields on the form + to the model.cto)
2. A nurse either requests it(log may not be imp.) through our system or somehow gets access to the document.
3. The nurse modifies the ccda & uploads it through our system - the docId and name will be captured.
4. We run a node file in the CLI which inputs the doctorId, name and check if any uploadCCDA transactions are present after the last one of the docId entered. We print the details on the CLI.

• The "treatment_complete" flag(boolean) specifies whether the doctor will be uploading more ccdas later.

step 4. on the deployed system may look like(for context) - The next time when the doctor accesses our system, he will be sent a notification that the ccda has been modified, take a look at the diff, and report it as malicious/safe.

The task is to make the changes and try this workflow out.

1. Implement the business network in Composer.

   1. Implement CCDA ownership transfer

2. Connecting Composer to the node backend

   1. Check if Hyperledger provides a node SDK or find the other way to connect to the blockchain(probably with REST APIs)
   2. Try submitting client requests from node.

The current implementation of app.post() in hie.js, only handles the file upload. In addition to this, the EHR also needs to send some metadata, in JSON. The receiving and storing of metadata is to be handled.

Data to be collected for creation of block -

1. patient id
2. ehr id
3. doctor id
4. MRN

The received data can be stored in an object, for now.
e.g - metadata_part = {pat_id: 123, ehr_id: 456, doc_id: 789, mrn: 123}

• Collect data from the body of the request, for the JSON format.
• Create a js object with the data in dummy_ehr and send it over the POST request.
  Note: ehr_id can be fetched from .env file, for now.

• The current audit.js code just displays the AddAsset transactions(not actually an audit)

• We need to list all accesses to the CCDA of a particular patient.

Procedure:

1. Query for the StartTransfer Transaction
2. Use JOINs(on the common field: StartTransId=timestampId) or a separate query to get the associated FinishTransfer & Local Access Transaction

• The final result should be a list of items with each item containing the following fields = {Patient_id, Patient_name, Doctor_id, Doctor name, Successful(true/false), ccda_hash, Reason for Access}
• Print in on the console in the tabular format or anything else that looks good.

The .env file must be used to store hardcoded values, like ehr_id, wherever possible. Rename the file after it is received at HIE, as files will be searched based on their MRN.

Tasks -

• Create an .env file. Read ehr_id in dummy ehr, port number in hie.
• Rename the uploaded file as MRN.xml
  • Precondition: Check if metadata has been received.(flag)

Here are some of the tasks which would be good to be done with, as we're concluding the project:

• README file, how to install & run. (ehr.js needs to run with node, not nodemon)

In the current implementation, a record is requested given its MRN, but in the real process, the EHR doesn't have this information. It just has the patient's identification information like name, ssn. The EMPI will give us the patient's global_id, with which we can lookup the latest record in the record chain.

Tasks -

• Create a Table in MySQL with attributes as global_id, name, ssn, ...
• Add a new API endpoint(GET), accepting query params like name, ssn, zipcode, etc.
• Send a query to the DB. (try SQL procedures for abstraction)

1. Use console inputs for all hardcoded values.
2. Remove all unnecessary console logs, used for debugging.

When the Requester request the Provider, the Provider must -

1. Check for the StartTransfer transaction on the chain (wait for a specific time interval for the changes to be affected, use setTimeout() and setInterval())
2. Authenticate the web service request with an API key. Design for this use case.

The API Key may be from the model file for a clinic. Also, look at current systems using API Key.

One possibility could be -

1. Send a request to the Provider for an API Key, stored on providers and requesters local mysql db, just once.
2. Use the API Key to request access to all ccdas in the future.
   Here, we're using the API Key as an identifier, which is also a shared secret.