The first step is to understand how System
would receive CCDA files. In case when we have an user-facing application like Patient
Portal or EHR user will upload his CCDA file manually. The other common case is bulk import
from remote storage like SFTP server or S3 bucket.
Processing received files is
usually a resource consuming task, so it’s better to make it asynchronous. This way our
system would be responsive while the file is being converted, and the entire conversion
process would be much more manageable. For example, we may notice a bug in the CCDA
converting logic, our engineers will fix it and we would like to process all recently
received files. Holding all received files in a queue will give you this
ability.
There are dozens of ways to set up such a queue, probably the most simple
one is to use the
DocumentReference
resource (if we know a patient to whom this document belongs). Alternatively we can use a
dedicated queue service like
Apache Kafka or just a
custom table in our RDBMS. However, despite the storage we would use, we would store the
original CCDA file to be able to access it at any time.
On the next step some kind of
background job or a worker will pick received files from a queue and process them one after
another.