Bitcoin, like most other blockchains, has a well-ordered collection of blocks. However, because the longest valid chain is the correct one, it may happen that, at a particular time, it's not clear which chain is valid (say, if there are two competing proposals for block N). This will almost certainly be resolved in the future in favour of one chain or the other, as one is built on and the other is not. Provided you specify some defined format of the chain to hash, you can use this value as a hash input, but you may want to wait for a few blocks to be sure that you don't have competing chains.
Now, whether you should use this for a PRNG or other secret input is different. If you want a secret input, this is not helpful, because if your project is interesting enough, it's possible for a mining group to get together and only attempt to mine blocks that would produce a certain outcome. For example, if you had a coin flip that determined who would win a large amount of money, it might be interesting to mine only the block that would let a certain person win. This becomes more complicated if there are many possible outcomes, since it increases the complexity of the attack, but in general, you cannot assume the output of a blockchain is random and free of influence. This is true even if multiple parties agree on a future block hash (say, N + 5). That would still provide the same incentive to attack the PRNG.
If you're looking to have a group of people agree on a secret seed ahead of time, each person can generate a random 256-bit secret $ S $, and then commit to it using a commitment scheme (such as the output of $ HMAC-SHA256(K, S) $ with a per-user random 256-bit $ K $). Everyone shares their commitment ahead of time, and then reveals their $ K $ and $ S $, and the $ S $ values can be used in a fixed order for a hash or seed. If you need to not reveal the value of the PRNG ahead of time (say, for playing a card game), you can send the $ S $ values to one person (the dealer), and then reveal the commitments at the end.